Où les virtualenvs doivent-ils être créés ?

Question

Je ne sais pas où je dois placer mes virtualenvs.

Avec mon premier projet django, j'ai créé le projet avec la commande

django-admin.py startproject djangoproject

J'ai ensuite accédé au répertoire djangoproject et lancé la commande

virtualenv env

qui a créé le répertoire de l'environnement virtuel au même niveau que l'environnement interne. djangoproject répertoire.

Est-ce le mauvais endroit pour créer le virtualenv pour ce projet particulier ?

J'ai l'impression que la plupart des gens gardent tous leurs virtualenvs ensemble dans un répertoire complètement différent, par exemple. ~/virtualenvs et utilisez ensuite virtualenvwrapper pour passer de l'un à l'autre.

Existe-t-il une manière correcte de procéder ?

Answer 1

De nombreuses personnes utilisent le virtualenvwrapper qui permet de conserver tous les virtualenvs au même endroit (l'outil ~/.virtualenvs ) et permet des raccourcis pour les créer et les conserver à cet endroit. Par exemple, vous pouvez faire :

mkvirtualenv djangoproject

et puis plus tard :

workon djangoproject

C'est probablement une mauvaise idée de garder le répertoire virtualenv dans le projet lui-même, puisque vous ne voulez pas le distribuer (il pourrait être spécifique à votre ordinateur ou système d'exploitation). Au lieu de cela, conservez un fichier requirements.txt en utilisant la commande pip :

pip freeze > requirements.txt

et le distribuer. Cela permettra aux autres utilisateurs de votre projet de réinstaller toutes les mêmes exigences dans leur virtualenv avec :

pip install -r requirements.txt

Answer 2

Le changement de l'emplacement du répertoire virtualenv le brise

C'est l'un des avantages de placer le répertoire en dehors de l'arborescence du référentiel, par exemple sous le nom de ~/.virtualenvs con virutalenvwrapper .

Sinon, si vous le gardez dans l'arbre du projet, le déplacement de l'emplacement du projet brisera le virtualenv.

Voir : Renommer un dossier virtualenv sans le casser

Hay --relocatable mais il est connu pour ne pas être parfait.

Autre petit avantage : vous n'avez pas à .gitignore il.

Les avantages de le mettre en gitignoring dans l'arbre du projet lui-même sont les suivants :

• permet de garder les éléments connexes à proximité les uns des autres.
• il est probable que vous ne réutiliserez jamais un virtualenv donné dans plusieurs projets, donc le placer ailleurs ne présente pas beaucoup d'avantages.

C'est un défaut de conception gênant à mon avis. Ils devraient implémenter virutalenv d'une manière qui ne tienne pas compte de l'endroit où se trouve le répertoire, car le stockage dans l'arbre est simplement plus simple et plus isolé. Le gestionnaire de paquets NPM de Node.js le fait sans aucun problème. Et pendant que nous y sommes, pip devrait utiliser les répertoires locaux par défaut, comme NPM. Avoir cette couche séparée de virtualenv est bancal. Node.js a juste NPM qui fait tout cela sans saisie supplémentaire. Je n'arrive pas à croire que je fais l'éloge de l'écosystème JavaScript dans un billet sur Python, mais c'est vrai.

Answer 3

L'endroit généralement accepté pour les placer est le même que celui où l'installation par défaut de virtualenvwrapper les place : ~/.virtualenvs

Related : virtualenvwrapper est un excellent outil qui fournit des raccourcis pour les commandes courantes de virtualenv. http://www.doughellmann.com/projects/virtualenvwrapper/

Answer 4

Si vous utilisez pyenv install Python alors pyenv-virtualenv sera une bonne pratique. Si les .python-version il peut activer ou désactiver automatiquement l'environnement virtuel lorsque vous changez de dossier de travail. Pyenv-virtualenv mettre également tous les env virtuels dans $HOME/.pyenv/versions dossier.

Answer 5

D'après mon expérience personnelle, je recommande d'organiser tous les environnements virtuels dans un seul répertoire. À moins que quelqu'un ait une mémoire extrêmement fine et puisse se souvenir des fichiers/dossiers éparpillés dans le système de fichiers. Je ne suis pas un grand fan de l'utilisation d'autres outils uniquement pour gérer les environnements virtuels. Dans VSCode, si je configure( python.venvPath ) contenant tous les environnements virtuels, il peut les reconnaître automatiquement.