Est-ce mauvais d’avoir mon répertoire virtualenv dans mon référentiel git?

Question

Je pense mettre la virtualenv pour une application web Django que je crée dans mon référentiel git pour l'application. Cela semble être un moyen facile de garder le déploiement simple et facile. Y a-t-il une raison pour laquelle je ne devrais pas faire cela?

Je suis totalement nouveau dans virtualenv, alors il y a de fortes chances pour que ce soit une question vraiment stupide.

Answer 1

J’utilise gel pip pour obtenir les paquets que j’ai besoin dans un requirements.txt de fichiers et d’ajouter que, pour mon dépôt. J’ai essayé d’imaginer un moyen de pourquoi vous voulez stocker la totalité virtualenv, mais je ne pouvais pas.

Answer 2

Le stockage de la virtualenv répertoire dans le répertoire git sera, comme vous l'avez remarqué, vous permettent de déployer l'ensemble de l'application il vous suffit de faire un git clone (en plus de l'installation et la configuration d'Apache/mod_wsgi). Un potentiellement importantes problème avec cette approche est que sur Linux, le chemin d'accès complet obtient codé en dur dans le venv de l'activer, django-admin.py, easy_install, et pip scripts. Cela signifie que votre virtualenv ne sera pas entièrement de travail si vous souhaitez utiliser un autre chemin, peut-être exécuter plusieurs serveurs virtuels sur un même serveur. Je pense que le site web peut travailler avec les chemins de mal dans ces fichiers, mais vous avez des problèmes la prochaine fois que vous avez essayé d'exécuter le programme pep.

La solution, déjà donné, est de stocker suffisamment d'informations dans git, de sorte que, pendant le déploiement, vous pouvez créer le virtualenv et faire le nécessaire pip installe. Généralement, les gens courent pip freeze pour obtenir la liste puis le stocker dans un fichier nommé requirements.txt. Il peut être chargé avec des pip install -r requirements.txt. RyanBrady déjà montré comment vous pouvez de la chaîne de la déployer des déclarations en une seule ligne:

virtualenv --no-site-packages --distribute .env && source .env/bin/activate && pip install -r requirements.txt

Personnellement, je viens de le mettre dans un script shell que j'ai exécuté après avoir fait le git clone ou git pull.

Le stockage de la virtualenv répertoire rend aussi un peu plus compliqué à gérer pip mises à niveau, que vous allez avoir à ajouter/supprimer et valider les fichiers résultant de la mise à niveau. Avec un requirements.txt fichier, il suffit de changer les lignes appropriées dans requirements.txt et ré-exécutez pip install -r requirements.txt. Comme l'a déjà noté, ce qui réduit également "s'engager spam".

Answer 3

J’ai utilisé pour faire la même chose jusqu'à ce que j’ai commencé à utiliser des bibliothèques compilés différemment selon l’environnement comme PyCrypto. Mon PyCrypto mac ne fonctionnerait pas sur Cygwin ne fonctionnerait pas sur Ubuntu.

Il devient un cauchemar absolu pour gérer le référentiel.

De toute façon je l’ai trouvé plus facile à gérer le gel pip & un fichier d’exigences que d’avoir tout dans git. C’est plus propre aussi puisque vous obtenez d’éviter le spam de validation pour des milliers de fichiers mis à jour les bibliothèques...

Answer 4

Je pense que l'un des principaux problèmes qui se produisent, c'est que le virtualenv pourrait ne pas être utilisable par d'autres personnes. La raison est qu'il toujours utiliser le chemin d'accès absolu. Donc, si vous virtualenv était par exemple en /home/lyle/myenv/ il assumera la même pour toutes les autres personnes de l'utilisation de ce référentiel (il doit être exactement le même chemin absolu). Vous ne pouvez pas présumer de personnes utilisant la même structure de répertoire que vous.

Il est préférable que tout le monde est à créer leur propre environnement (que ce soit avec ou sans virtualenv) et l'installation de bibliothèques. Qui vous rend également le code plus utilisable sur différentes plates-formes (Linux/Windows/Mac), aussi parce que virtualenv est installé différente dans chacun d'eux.