Vous n'êtes pas identifié(e).
Est-ce correct ? En tous cas cela fonctionne.
On débâtera sur l'import nécessaire aux modules après
Merci de vos réponses.
Dernière modification par Tawal (06-10-2024 13:28:32)
Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !
Hors ligne
quitte à copier-coller le module dans plusieurs projets si besoin.
J'ai par exemple des petits bouts d'interface en ligne de commande (coloration, barre de progression) que je copie colle dans un projet lorsque nécessaire.
La méthode permet de rendre le projet facilement portable, un seul dossier à dupliquer, pas de code à modifier.
Le module est déjà accessible dans le pythonpath, un simple import suffit.
SI tu souhaites partager ton module entre plusieurs projets, je vois plusieurs méthodes alternatives:
1. modifier le path python en modifiant la variable d'environnement:
Dans ton shell
Puis dans ton script python:
Ca revient au même que ton code python, mais ça me semble plus "conventionnel"
2. créer un paquet et l'installer
Là c'est déjà plus complexe, mais si tu veux bien emballer ton module dans quelque chose de propre et facilement utilisable, tu peux regarder par là. (c'est pas si compliqué que ça en vrai )
Avec setuptools par exemple
On peut imaginer l'installer dans un environnement virtuel que tu n'aura qu'a activer quand tu en aura besoin:
Quand tu as besoin du module, avant de lancer ton programme :
Et dans ton script python, un simple:
Voilà, c'est quelques pistes, peut-être y aura t'il des réponses plus pertinentes et rigoureuses sur la question des imports, mais c'est ce que je ferai spontanément.
PS : toujours travailler dans un environnement virtuel est une bonne pratique (pas de risque de casser son système, plus facile de contrôler la versions des paquets installés, plus facile à porter son projet sur un autre appareil...
Dernière modification par David5647 (03-10-2024 16:23:17)
Hors ligne
Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !
Hors ligne
Code principal
Quelques soit le répertoire du code principal il importera le fichier machin.py (s’il a les droits en lecture sur le fichier évidemment)
Note que la lecture du PYTHONPATH avant te montre que l’ensemble des modules de la distribution python sont déjà accessibles.
chez moi cela donne :
'/usr/lib/python3.11/os.py'
Tousse antique Ovide !
Hors ligne
Reste à transférer proprement les modules persos vers le nouveau répertoire de la (nouvelle) version Python …
Edit3:
Pourquoi je dis ça ?
Avec sys.version, un script peut facilement "fabriquer" le chemin vers les libs python locales (/usr/local/lib/python….).
Mais en cas de montée en version de Python, je ne suis pas sûr que les fichiers de /usr/local/lib/python_version_old soient transférés vers le nouveau dossier local de la version nouvellement installée.
Je pense d'ailleurs que lors de la montée en version de Python, apt m'avertira qu'il ne peut pas supprimer le répertoire /usr/local/lib/python… de l'ancienne version.
Donc MES fichiers seront toujours dans le répertoire de l'ancienne version et le répertoire de la nouvelle sera vide.
D'où le transfert nécessaire.
Dernière modification par Tawal (05-10-2024 16:30:31)
Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !
Hors ligne
Du coup si tu changes tes modules de place il n’y a plus qu’à modifier cette ligne.
Tousse antique Ovide !
Hors ligne
EDIT:
J'ai résolu mon problème avec l'application Golly :
Il est dit dans la documentation que Golly exécute au démarrage un fichier golly-start.py.
J'ai cherché ce fichier, il n'existe pas.
Je l'ai créé dans le répertoire de l'application avec ce contenu :
Et ça fonctionne.
Il me suffit ensuite d'importer le fichier voulu dans un script comme ceci par exemple :
Dernière modification par Tawal (06-10-2024 13:11:50)
Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !
Hors ligne
Mon script :
Bref, ça vaut vraiment un autre sujet.
Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !
Hors ligne
Je ne pense pas que bricoler les fichiers et répertoires de la distribution soit un bonne idée.
/usr/local, contrairement au reste de /usr, n’est pas un chemin utilisé par la distribution. Au contraire celui-ci est réservé à l’administrateur local de la machine.
En ligne
Tousse antique Ovide !
Hors ligne
…
/usr/local, contrairement au reste de /usr, n’est pas un chemin utilisé par la distribution. Au contraire celui-ci est réservé à l’administrateur local de la machine.
Oui, généralement. Et c'est ce que je pensais.
Mais je n'ai en aucun cas créé le répertoire /usr/local/lib/python3.11
C'est donc bien la distribution qui gère ce répertoire, non ?
Pour sûr, si Python passe à la version 3.12, j'aurais un répertoire /usr/local/lib/python3.12.
Et les fichiers personnels dans /usr/local/lib/python3.11 ne seront pas transférés vers l'autre.
Bref, on dépend de la version/distribution.
Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !
Hors ligne
Mais je n'ai en aucun cas créé le répertoire /usr/local/lib/python3.11
C'est donc bien la distribution qui gère ce répertoire, non ?
A priori oui.
Pour sûr, si Python passe à la version 3.12, j'aurais un répertoire /usr/local/lib/python3.12.
Et les fichiers personnels dans /usr/local/lib/python3.11 ne seront pas transférés vers l'autre.
Bref, on dépend de la version/distribution.
Je le pense aussi puisque je n’ai pas trace d’un répertoire python3.9. Sauf si la création de ce répertoire est une nouveauté de debian12. vv222 a peut-être une explication à ce sujet.
Sinon le seul répertoire /usr/local sur lequel le sys.path pointe par défaut est le répertoire /usr/local/lib/python3.11/dist-packages et aucunement vers /usr/local/lib/python3.11.
Tousse antique Ovide !
Hors ligne
Mais je n'ai en aucun cas créé le répertoire /usr/local/lib/python3.11
C'est donc bien la distribution qui gère ce répertoire, non ?
En effet, c’est créé par un script fourni par le paquet python3.11-minimal, justement pour que ce soit à disposition de l’administrateur de la machine.
À mon avis c’est un mauvais choix de la part du mainteneur du paquet Debian, un administrateur ayant besoin de ces chemins devrait bien être capable de les créer lui-même.
En ligne