Je pense qu'il n'y a pas vraiment de meilleure approche car l'organisation choisie va dépendre du flux de travail utilisé.
J'ai lu quelque part que certaines personnes font un dossier dans leur home qui contient l'ensemble de leurs environnements virtuels, mais ça me semble être peu pratique pour retrouver le bon environnement à activer pour le bon projet.
L'approche d'un dossier contenant tous les environnements virtuels est celle imposée par virtualenvwrapper et pew On retrouve facilement le bon environnement à activer en le nommant correctement : je conseille de lui donner le même nom que le projet...
Aujourd'hui je crée le venv dans le dossier où est aussi le code, dans un dossier ".venv". Et j'exclue ce dossier dans mon .gitignore
En fait c'est pareil : est-ce que tu préfères, dans ta matrice de travail, que les environnements Py soient en abscisses ou en ordonnées :-) Dans l'approche précédente, je mettrai par exemple les sources dans un sous-répertoire $venv/src et c'est ce dernier qui sera versionné. Le principal avantage dans ce cas, comparé à l'autre organisation, est de ne pas polluer le .gitignore (je trouve que c'est une mauvaise pratique et un mauvais signe quand on y retrouve des trucs relatifs à son organisation perso quand on doit travailler en équipe)
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Où placer ses environnements virtuels et comment les nommer ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse à la dépêche Python — partie 7 — Environnements virtuels. Évalué à 3.
Je pense qu'il n'y a pas vraiment de meilleure approche car l'organisation choisie va dépendre du flux de travail utilisé.
L'approche d'un dossier contenant tous les environnements virtuels est celle imposée par
virtualenvwrapperetpewOn retrouve facilement le bon environnement à activer en le nommant correctement : je conseille de lui donner le même nom que le projet...En fait c'est pareil : est-ce que tu préfères, dans ta matrice de travail, que les environnements Py soient en abscisses ou en ordonnées
:-)Dans l'approche précédente, je mettrai par exemple les sources dans un sous-répertoire$venv/srcet c'est ce dernier qui sera versionné. Le principal avantage dans ce cas, comparé à l'autre organisation, est de ne pas polluer le.gitignore(je trouve que c'est une mauvaise pratique et un mauvais signe quand on y retrouve des trucs relatifs à son organisation perso quand on doit travailler en équipe)"It is seldom that liberty of any kind is lost all at once." ― David Hume