path mis dans PYTHONPATH

Version imprimable

Bonjour,
je pensais que PYTHONPATH pouvait inclure plusieurs "paths", le cas suivant montre que non ou alors je ne comprends pas la logique associée : j'ai interverti les deux paths mis dans PYTHONPATH, ce qui fait marcher ou pas mon application.
Code:

1 2 3 4 5 6 7 8 9 10 11 >awalter>: setenv PYTHONPATH /ipas2/user/awalter/ccm_wa/NEDI-ACE2011A_prep/NEDI:/ipas2/user/awalter/ccm_wa/AIXM-ACE2011A_prep/AIXM >awalter>: python /ipas2/user/awalter/ccm_wa/AIXM-ACE2011A_prep/AIXM/HMI/main_export.py -u IPAS0 -s ACE2011A Traceback (most recent call last): File "/ipas2/user/awalter/ccm_wa/AIXM-ACE2011A_prep/AIXM/HMI/main_export.py", line 18, in ? from DataInterface.databaseaixm import DataBaseAixm__,Handler__ ImportError: No module named databaseaixm >awalter> >awalter>: setenv PYTHONPATH /ipas2/user/awalter/ccm_wa/AIXM-ACE2011A_prep/AIXM:/ipas2/user/awalter/ccm_wa/NEDI-ACE2011A_prep/NEDI >awalter>: python -O /ipas2/user/awalter/ccm_wa/AIXM-ACE2011A_prep/AIXM/HMI/main_export.py -u IPAS0 =>Quit AIXM Application ! >awalter>:
Quelqu'un peut 'il m'expliquer ce qui cloche ?

Le souci est que j'ai un pb python (localisé par le path a) doit lancer un autre pg python (localisé par le path b), comment faire dans ce cas pour positionner PYTHONPATH si ce qui est cité plus haut est confirmé.
Merci

Bonjour.

Citation:

Envoyé par awalter1

... j'ai un pg python (localisé par le path a) doit lancer un autre pg python (localisé par le path b), comment faire dans ce cas ...

Voici une méthode qui marche sous les systèmes Unix. Pour Windows, il faudra peut-être donner précisément le chemin de Python dans le 1er élément de la liste des arguments (cf. code) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #!/usr/bin/env python3 import subprocess import os currentDirectory = os.path.dirname( __file__ ) currentDirectory = os.path.normpath(currentDirectory) pathOfThePythonFileToCall = os.path.join(currentDirectory, 'called.py') try: subprocess.check_call(cwd = currentDirectory, args = ['python', # Windaube ? pathOfThePythonFileToCall]) except: print('The Python file cannot be called.')
Le code du fichier appelé :
Code:

1 2 3 4 5 6 7 8 9 10 11 #!/usr/bin/env python #coding=utf-8 import time lastCall = time.strftime('%d-%m-%Y_%H-%M-%S', time.localtime()) # We use the syntax of print in Python 2 # so as to see that Python 2 has been called. print lastCall
Dans cet exemple, le 1er code est lancé depuis Python 3 et il appelle le 2nd sous Python 2.6.

Rien n'empêche de faire des appels avec la même version de Python.

PS : pour ceux qui sont sous Windows, je suis preneur des modifications qu'il faut apporter.

26/01/2011, 17h21
Antoine_935

10 contre 1 que vous avez un module DataInterface dans "/ipas2/user/awalter/ccm_wa/NEDI-ACE2011A_prep/NEDI".
26/01/2011, 17h33
rambc

Bonjour Antoine.

Peux-tu nous en dire plus ?

PS : sur ce, je vais aller nager.
26/01/2011, 17h54
Antoine_935

Bien sur :)

Pour charger un module, python regarde dans toutes les entrées du PYTHONPATH une à une, en commençant évidemment par la première.

Dès qu'il trouve le module, il arrête la recherche.
Du coup, il se pourrait tout à fait qu'il trouve un module DataInterface dans le premier dossier. Module qu'il charge, pour ensuite découvrir qu'il n'y a pas de sous-module nommé databaseaixm dedans.

Dans l'autre sens, tout fonctionne bien. La seule conclusion logique que je vois, c'est que le module DataInterface est présent dans les deux dossiers, mais que celui de NEDI ne contient pas databaseaixm.

PS: awalter, vous avez certainement fait du java :)
27/01/2011, 11h05
awalter1

Bonjour,
Oui Antoine, vous avez raison, tous mes projets répondent à la même structure et donc ont un répertoire DataInterface. J'aurais pu y penser.
Je vais essayer la solution proposée plus haut ou l'adapter car je suis en python 2.4.4 sous Linux.
Merci
27/01/2011, 11h21
awalter1

Je ne comprends pas la solution de rambc :
current_directory va fournir le path du programme appelant (celui qui s'exécute) et pas celui à appeler ?
Merci
27/01/2011, 11h54
rambc

Bonjour.

Citation:

Envoyé par awalter1

Je ne comprends pas la solution de rambc :
current_directory va fournir le path du programme appelant (celui qui s'exécute) et pas celui à appeler ?

En fait dans le cadre de mon exemple, j'avais mis le fichier appelé et celui appelant dans le même dossier.

A toi de remplir pathOfThePythonFileToCall avec le bon chemin de ton fichier à appeler.
27/01/2011, 12h13
awalter1

Ben ça marche pas !
Le pb n'est pas dans le lancement de "called.py", mais dans les imports de fichiers qui sont faits dans son code et ces imports sont pilotés par PYTHONPATH si j'ai bien compris.
j'ai trouvé la solution de modifier le PYTHONPATH par os.putenv avant d'appeler "called.py" et je repositionne le PYTHONPATH d'origine après la fin d'exécution de "called.py", je ne sais pas si c'est propre mais cela fonctionne.
Merci

PS: d'ailleurs je crois qu'au lancement d'une appli python, tous les imports sont testés (effectués ?) même ceux de fichiers py qui ne sont pas exécutés. Cela veut t'il dire que PYTHONPATH n'est lu qu'au lancement de l'appli et plus après ? auquel cas, modifier le PYTHONPATH dans un pg python n'a pas d'incidence sur le déroulement de celui-ci.
27/01/2011, 12h16
rambc

Citation:

Envoyé par awalter1

j'ai trouvé la solution de modifier le PYTHONPATH par os.putenv avant d'appeler "called.py" et je repositionne le PYTHONPATH d'origine après la fin d'exécution de "called.py", je ne sais pas si c'est propre mais cela fonctionne.

Ok. Peux-tu mettre un exemple ici ?
27/01/2011, 13h02
kango

Citation:

Envoyé par awalter1

PS: d'ailleurs je crois qu'au lancement d'une appli python, tous les imports sont testés (effectués ?) même ceux de fichiers py qui ne sont pas exécutés. Cela veut t'il dire que PYTHONPATH n'est lu qu'au lancement de l'appli et plus après ? auquel cas, modifier le PYTHONPATH dans un pg python n'a pas d'incidence sur le déroulement de celui-ci.

Pour PYTHONPATH il est en effet lu au lancement de l'interpréteur. Si tu réinvoques l'interpréteur Python pour lancer le second script, la variable d'environnement va être lue à nouveau. Comme le second script est un enfant du premier, il hérite de son environnement. C'est pourquoi l'astuce avec le putenv fonctionne.

Une autre solution consisterait à modifier sys.path. Du coup la modif est prise en compte pour les imports qui interviennent après (et après uniquement).

Dernière alternative, installer les modules dans le répertoire site-packages de Python en utilisant par exemple les distutils.

Citation:

Envoyé par rambc

Ok. Peux-tu mettre un exemple ici ?

Voici mon code:

Code:

1
2
3
4
5
6
		path = "/ipas2/user/awalter/ccm_wa/AIXM-ACE2011A_prep/AIXM"
		os.putenv("PYTHONPATH",path) 
		command_to_launch = "python -O  %s/HMI/main_export.py -u %s -p %s" % (path,self.database.user -p self.database.password)
		retcode = os.system(command_to_launch)		
		if retcode/256 == 8:
			print "Export OK"

24/04/2014, 23h59
Vincent34

Bonjour,

Je déterre ce post pour poser une question en lien avec les codes proposés ici. Je suis sous Debian.

Le code proposé par rambc fonctionne bien, mais comme l'a souligné kango (si j'ai bien compris), le module annexe 'called.py' est bien lu, mais aucune variable de ce module n'est stocké dans le script principal.
Je le regrette, car je souhaitais conserver deux fonctions d'un module python3. Je peux effectivement les print depuis le module 'called.py', mais elles ne sont pas stockées en variables globales dans mon main script en python2.

Y a-t-il une ruse pour pouvoir bénéficier du script de rambc tout en conservant la variable (lastcall), qui me permettrait ainsi de conserver dans un script python2 les variables d'un script python3 ?

P.S : si malheureusement, il m'aurait fallu ouvrir un nouveau fil avec ma question, merci de me le faire savoir et excusez mon erreur.