Utiliser git pour gérer l'état de virtualenv : cela va-t-il poser des problèmes ?

Question

J'ai actuellement configuré git et virtualenv d'une manière qui correspond exactement qui répond exactement à mes besoins et qui, jusqu'à présent, n'a causé aucun problème. Cependant, je suis conscient que Cependant, je suis conscient que ma configuration n'est pas standard et je me demande si quelqu'un qui est plus familier avec les peut m'indiquer si, et où, il y a des risques de problèmes.

Mon installation

Mon virtualenv se trouve à l'intérieur de mon dépôt git, mais git est configuré de manière à ignorer l'option bin et include et tout ce qui se trouve dans lib sauf pour le site-packages répertoire.

Plus précisément, mon .gitignore ressemble à ceci :

*.pyc

# Ignore all the virtualenv stuff except the actual packages
# themselves
/bin
/include
/lib/python*/*
!/lib/python*/site-packages

# Ignore easyinstall and setuptools
/lib/python*/site-packages/easy-install.pth
/lib/python*/site-packages/setuptools.pth
/lib/python*/site-packages/setuptools-*
/lib/python*/site-packages/pip-*

Avec cet arrangement, je -- et toute autre personne travaillant sur un checkout du projet -- peux utiliser virtualenv et pip comme d'habitude mais avec les avantages suivants :

1. Si quelqu'un met à jour ou installe un paquet et envoie ses modifications, toute autre personne qui envoie ces modifications reçoit automatiquement la mise à jour : elle n'a pas besoin de remarquer qu'un paquet de type requirements.txt a été modifié ou si vous faites post-receive la magie du crochet.

2. Il n'y a pas de dépendances réseau : tout le code nécessaire au fonctionnement de l'application se trouve dans le dépôt git.

Je suis conscient que cela ne fonctionne qu'avec les paquets purement Python, mais c'est tout ce qui m'intéresse pour le moment.

Quelqu'un connaît-il d'autres problèmes liés à cette approche dont je devrais être conscient ?

Answer 1

C'est une question intéressante. Je pense que les deux autres réponses (jusqu'à présent) soulèvent de bons points spécifiques. Il est clair que vous y avez réfléchi et que vous êtes arrivé à une solution qui vous plaît, mais je note qu'il semble y avoir une division philosophique parmi les utilisateurs de virtualenv.

Un camp, auquel je suppose que vous appartenez, estime que l'EV locale fait partie du projet (c'est-à-dire qu'elle doit être sous contrôle de version). L'autre camp estime que l'EV doit essentiellement être traitée comme un artefact de développement -- que le fichier requirements.txt doit faire partie du dépôt du projet, mais que vous devez être en mesure de supprimer et de recréer l'EV si nécessaire.

Je mentionne simplement ceci parce que lorsque j'ai vu cette distinction pour la première fois, elle a contribué à façonner ma réflexion sur virtualenv. (Je suis dans le second camp, FWIW, parce que cela me semble plus simple et plus propre, mais cela ne veut pas dire qu'être dans le premier camp est mauvais pour votre projet particulier).

Answer 2

Si vous avez -e dans votre requirements.txt - en d'autres termes, si vous avez des dépendances modifiables telles que décrites dans la section format qui utilisent le git système de contrôle de version, vous rencontrerez très probablement des problèmes quand votre src est engagé. Si vous ajoutez simplement /src à votre .gitignore vous pouvez alors éviter ce problème, mais souvent l'installation se contente d'ajouter un pointeur en site-packages à cet endroit, alors vous en avez besoin !

Answer 3

Sur /lib/python2.7/site-packages dans mon virtualenv j'ai des chemins absolus, par exemple dans Django.egg-link J'ai /Users/henry/.virtualenv/mowapp/src/django (il s'agit d'un Mac).

Vérifiez si vous avez des chemins absolus enregistrés dans git, je pense que c'est un problème majeur avec cette approche.