Est-ce mauvais d’avoir mon répertoire virtualenv dans mon référentiel git?
Je pense mettre la virtualenv pour une application web Django que je crée dans mon référentiel git pour cette 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?
J'utilise pip freeze pour obtenir les packages dont j'ai besoin dans un fichier requirements.txt et les ajouter à mon référentiel. J'ai essayé de trouver un moyen de vouloir stocker l'ensemble de la virtualité, mais je ne pouvais pas.
Comme vous l'avez indiqué, le fait de stocker le répertoire virtualenv dans git vous permettra de déployer l'application dans son intégralité en effectuant un clone (en plus d'installer et de configurer Apache/mod_wsgi). Un problème potentiellement important de cette approche est que sous Linux, le chemin complet est codé en dur dans les scripts activate, Django-admin.py, easy_install et pip de venv's. Cela signifie que votre virtualenv ne fonctionnera pas entièrement si vous voulez utiliser un chemin différent, peut-être exécuter plusieurs hôtes virtuels sur le même serveur. Je pense que le site Web peut en fait fonctionner avec les mauvais chemins dans ces fichiers, mais vous auriez des problèmes la prochaine fois que vous essayez d'exécuter pip.
La solution, déjà donnée, consiste à stocker suffisamment d’informations dans git pour pouvoir créer virtualenv et effectuer les installations de pip nécessaires lors du déploiement. Généralement, les gens exécutent pip freeze pour obtenir la liste, puis la stockent dans un fichier nommé exigences.txt. Il peut être chargé avec pip install -r requirements.txt. RyanBrady a déjà montré comment vous pouvez chaîner les instructions de déploiement en une seule ligne:
# before 15.1.0
virtualenv --no-site-packages --distribute .env &&\
source .env/bin/activate &&\
pip install -r requirements.txt
# after deprecation of some arguments in 15.1.0
virtualenv .env && source .env/bin/activate && pip install -r requirements.txt
Personnellement, je viens de les mettre dans un script Shell que je lance après avoir effectué le clonage ou le tirage de git.
Le stockage du répertoire virtualenv complique également la gestion des mises à niveau pip, car vous devrez ajouter/supprimer et valider manuellement les fichiers résultant de la mise à niveau. Avec un fichier Requirements.txt, il vous suffit de modifier les lignes appropriées dans Requirements.txt et de réexécuter pip install -r requirements.txt. Comme indiqué précédemment, cela réduit également le "spam spam".
J'avais l'habitude de faire la même chose jusqu'à ce que je commence à utiliser des bibliothèques compilées différemment selon l'environnement, tel que PyCrypto. Mon ordinateur PyCrypto ne fonctionnerait pas sur Cygwin ne fonctionnerait pas sur Ubuntu.
La gestion du référentiel devient un cauchemar.
Quoi qu’il en soit, j’ai trouvé qu’il était plus facile de gérer le gel et un fichier d’exigences que de tout avoir en place. C'est plus propre aussi puisque vous évitez le spam spam pour des milliers de fichiers lorsque ces bibliothèques sont mises à jour ...
Je pense que l’un des principaux problèmes qui se posent est que la virtualenv pourrait ne pas être utilisable par d’autres personnes. La raison en est qu'il utilise toujours des chemins absolus. Donc, si votre virtualenv était par exemple dans /home/lyle/myenv/, il en sera de même pour toutes les autres personnes utilisant ce référentiel (ce doit être exactement le même chemin absolu). Vous ne pouvez pas présumer que des personnes utilisent la même structure de répertoires que vous.
La meilleure pratique est que tout le monde configure son propre environnement (que ce soit avec ou sans virtualenv) et y installe des bibliothèques. Cela rend également votre code plus utilisable sur différentes plateformes (Linux/Windows/Mac), également parce que virtualenv est installé de manière différente sur chacune d’elles.
Si vous savez sur quels systèmes d'exploitation votre application sera exécutée, je créerais un virtualenv pour chaque système et l'inclurais dans mon référentiel. Ensuite, je ferais en sorte que mon application détecte le système sur lequel elle est exécutée et utilise le virtualenv correspondant.
Le système pourrait par exemple être identifié à l'aide du module plate-forme .
En fait, c’est ce que je fais avec une application interne que j’ai écrite et à laquelle je peux rapidement ajouter le nouveau système virtuel en cas de besoin. De cette façon, je n'ai pas à compter sur le fait que pip pourra télécharger avec succès le logiciel requis par mon application. Je n'aurai pas non plus à me soucier de la compilation, par exemple. psycopg2 que j'utilise.
Si vous ne savez pas sur quel système d'exploitation votre application peut s'exécuter, vous feriez probablement mieux d'utiliser pip freeze comme suggéré dans les autres réponses fournies ici.
J'utilise ce qui est fondamentalement réponse de David Sickmiller avec un peu plus d'automatisation. Je crée un fichier (non exécutable) au plus haut niveau de mon projet nommé activate avec le contenu suivant:
[ -n "$BASH_SOURCE" ] \
|| { echo 1>&2 "source (.) this with Bash."; exit 2; }
(
cd "$(dirname "$BASH_SOURCE")"
[ -d .build/virtualenv ] || {
virtualenv .build/virtualenv
. .build/virtualenv/bin/activate
pip install -r requirements.txt
}
)
. "$(dirname "$BASH_SOURCE")/.build/virtualenv/bin/activate"
(Selon la réponse de David, cela suppose que vous effectuez un pip freeze > requirements.txt pour tenir à jour votre liste d'exigences.)
Ce qui précède donne l’idée générale; le script réel activer ( documentation ) que j'utilise normalement est un peu plus sophistiqué, offrant une option -q (silencieux), utilisant python lorsque python3 n'est pas disponible, etc.
Celui-ci peut ensuite provenir de n’importe quel répertoire de travail en cours et s’activer correctement. Commencez par configurer l’environnement virtuel si nécessaire. Mon script de test de niveau supérieur a généralement du code le long de ces lignes afin qu'il puisse être exécuté sans que le développeur n'ait à activer au préalable:
cd "$(dirname "$0")"
[[ $VIRTUAL_ENV = $(pwd -P) ]] || . ./activate
Sourcing ./activate, pas activate, est important ici car ce dernier trouvera un autre activate dans votre chemin avant de trouver celui du répertoire en cours.
Si vous ne configurez que l'environnement de développement, utilisez alors pip freeze file, caz, qui permet de nettoyer le dépôt git.
Ensuite, si vous effectuez un déploiement de production, archivez tout le dossier venv. Cela rendra votre déploiement plus reproductible, ne nécessitera plus ces packages libxxx-dev et vous évitera les problèmes liés à Internet.
Donc, il y a deux pensions. Un pour votre code source principal, qui inclut un fichier Requirements.txt. Et un repo env, qui contient tout le dossier venv.