Discussion :

[awalter1]

Bonjour,
J'ais 2 applis python placées sous le même dossier parent. Ces applis étaient lancées séparément. A présent, je veux que l'appli A lance les fonctions de l'appli B.
Il faut que je fasse les imports des modules de l'appli B à partir de l'appli A, mais les applis étant au même niveau la syntaxe :
from ../AppliB/main import *
ne marche pas. Un path absolu non plus.
Si je modifie le PYTHONPATH pour remonter au parent commun, je vais être obligé de modifier toutes les lignes de code de l'appli A et l'appli B ou se font les import, non ?
Merci

[awalter1]

J'ai trouvé une solution qui est de faire connaitre l'appli B dans l'appli A, via un lien symbolique. C'est plus facile que je pensais.
A présent, j'ai la situation suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
>echo $PYTHONPATH
   /rsynergy/ccm_wa/AppliA-v1/AppliA/
 
>pwd
   /rsynergy/ccm_wa/AppliA-v1/AppliA/
 
>ls -l
   Include
   HMI
   AppliB -> /rsynergy/ccm_wa/AppliB-v0/AppliB/
 
>ls -l /rsynergy/ccm_wa/AppliB-v0/AppliB/
   Include
   HMI

SI je teste mes imports via une session python :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
python
>>>import Include.constantsA
>>>
>>>import NEDI.Include.constantsB
Traceback ....
ImportError : No module named NEDI.Include.constantsB

alors que ce fichier existe bien à l'endroit désigné : je modifie le sys.path :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
>>>import sys
>>>sys.path
['','/rsynergy/ccm_wa/AppliA-v1/AppliA/', ...]
>>>sys.path.append(/rsynergy/ccm_wa/AppliA-v1/AppliA/AppliB/Include)
>>>import constantsB
>>>

Pourquoi le "import NEDI.Include.constantsB" ne marche t'il pas alors qu'en modifiant le sys.path, on accède à constantsB ? Est ce du au lien symbolique que ne saurait pas interpréter python ?
Merci

[mont29]

Pourquoi ne pas simplement modifier le sys.path dans A pour y ajouter un chemin (relatif ou absolu) vers B*? Normalement, ça marche très bien…

[awalter1]

En effet, pourquoi pas. Je me demandais simplement pourquoi le chemin mis dans l'instruction import : "import NEDI.Include.constantsB" ne marchait pas.

[awalter1]

mais il va y avoir des conflits de noms : si j'ai dans le sys.path :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

['','/rsynergy/ccm_wa/AppliA-v1/AppliA/','/rsynergy/ccm_wa/AppliB-v0/AppliB/', ...]

comment distinguer des modules dont le chemin et le nom du module lui même existent dans les deux appli A et B.
Par exemple ces deux fichiers existent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
/rsynergy/ccm_wa/AppliA-v1/AppliA/Include/config.py
/rsynergy/ccm_wa/AppliB-v0/AppliB/Include/config.py

Merci

[rambc]

Bonjour.

J'ai passé trop de temps à jouer avec des imports relatifs. Une vraie galère !...

J'utilise maintenant distutils pour avoir mes projets dans ma distribution locale. Ceci peut être une piste à explorer si ton projet le permet.

[mont29]

En faisant de AppliB un module (suffit de rajouter dans le dossier un fichier __init__.py), tu peux faire import AppliB.foo.bar, et plus de problème de collision, non*?

[fred1599]

Chapitre 6.4 : Les packages

L'objectif est de créer un projet si j'ai bien compris, dans ce cas, c'est un package que tu dois créer.

[awalter1]

Bonjour,
J'avais lu ce chapitre sur les modules qui se résume à la formulation des imports. Il n'y a pas en fait de création de packages, si j'ai compris, le fait de faire un import fait d'un groupe de fichiers un package, en prenant la précaution de renseigner les fichiers __init__.py.
Dans mon cas, après quelques tests, le plus logique (et simple) est de mettre AppliB dans AppliA.

[awalter1]

Il reste néanmoins des comportements inexplicables, exemple avec la hierarchie suivante et un PYTHONPATH qui pointe vers AppliA :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
AppliA
   AppliB
      Include
         config.py
   main.py

Si dans main.py je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

import AppliB.Include.config

j'ai l'erreur ImportError. Il faut en fait ajouter un fichier __init_.py même vide au niveau de AppliB et Include :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
AppliA
   AppliB
      __init__.py
      Include
         __init__.py
         config.py
   main.py

Est ce un comportement normal ?
Merci

[mont29]

Oui, il faut un __init__.py à chaque niveau, sinon le dossier n’est pas considéré comme module, et donc pas “importable” via un “chemin de module” python.

[fred1599]

Oui c'est normal,

Tout cela est dans le chapitre que je t'ai demandé de lire, et en effet, il faut un fichier __init__.py vide ou non selon ce que tu veux.

Tu peux lire cela en français, si tu as des difficultés avec l'anglais.

[awalter1]

Je crois avoir résolu mes pb d'import : j'ai fixé mon PYTHONPATH afin qu'il n'indique que l'appli A, et j'ai modifié les imports fait par AppliB afin qu'il trouve ses propres modules. Je n'ai plus de ImportError.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
AppliA
   AppliB
      __init__.py
      Include
         __init__.py
         config.py
      main.py
   main.py
   Include
      __init__.py
      config.py

Dans AppliA/AppliB/main.py, je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

import AppliB.Include.config

Mais imports me semblent résolus.
Maintenant, je me retrouve avec l'effet de bord suivant, par exemple dans AppliA/main.py:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
import Include.config
print sys.path
Config__()    # c'est une classe de AppliA/Include/config.py

C'est la classe de AppliA/AppliB/Include/config.py qui est prise contre toute logique,au lieu de AppliA/Include/config.py !!! Comment peut t'on savoir (en mettant des traces dans le pg ou autrement) où python va t'il chercher les fonctions (ici Config__) ? Pour info, dans sys.path je n'ai que le path vers "AppliA".
Merci de votre aide

[awalter1]

Un test supplémentaire :
si je renomme la classe Config__ qui est dans AppliA/AppliB/Include/config.py en Config2__ alors c'est bien celle de AppliA/Include/config.py
Cela signifie que python va chercher dans l'ordre suivant :
AppliA/AppliB/Include/
AppliA/Include/

Qui lui dit de raisonner ainsi, je veux dire : c'est pas le PYTHONPATH, ce n'est pas les chemins dans mes instructions import qui sont non ambigus ...
Merci

[fred1599]

Tu te souviens quand j'ai dis

Tout cela est dans le chapitre que je t'ai demandé de lire, et en effet, il faut un fichier __init__.py vide ou non selon ce que tu veux.

Dans ton cas, il faudra utilser __all__ qui est une liste des fichiers se trouvant dans ton dossier et la placer dans ton __init__.py

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

__all__ = ["config"]

[awalter1]

Bonjour,
Dans les deux fichiers __init__ se trouvant respectivement dans :
AppliA/AppliB/Include/
AppliA/Include/
j'avais : __all__ = ["config"]
Cela n'explique donc pas pourquoi c'est le chemin AppliA/AppliB/Include/ qui est prioritaire.
Au cas ou, j'ai enlevé le "config" dans AppliA/AppliB/Include/__init__.py, c'est toujours AppliA/AppliB/Include/config.py qui est sélectionné en premier.
Merci