Using git to manage virtualenv state: will this cause problems?

I currently have git and virtualenv that exactly matches my needs and, so far, has not caused any problems. However, I know that my installation is non-standard, and I wonder if anyone more familiar with virtualenv's insides can indicate if and where this is likely to happen incorrectly.

My setting

My virtualenv is inside my git repository, but git is set to ignore the bin and include directories and everything in lib except for the site-packages directory.

More precisely, my .gitignore file looks like this:

 *.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-* 

With this arrangement, I - and anyone else who works on project verification - can use virtualenv and pip as usual, but with the following benefits:

  • If someone updates or installs a package and pushes their changes, anyone who pulls those changes automatically receives the update: they don’t need to notice that the requirements.txt file has changed or has done any post-receive hook magic.

  • There are no network dependencies: all the code to make the application work in the git repository.

I know this only works with pure-Python packages, but that's all I'm worried about at the moment.

Does anyone know of any other issues with this approach that I should be aware of?

+18
git python virtualenv
May 10 '11 at 19:54
source share
3 answers

If you have -e elements in requirements.txt - in other words, if you have any editable dependencies, as described in format , that use the git version control system, you will most likely run into problems when your src directory fixed. If you just added /src to your .gitignore , then you can avoid this problem, but often the installation simply adds a pointer to site-packages to this location, so you need it!

+6
May 14 '11 at 3:58 a.m.
source share

This is an interesting question. I think the other two answers (for now) raise good concrete points. It is clear that you thought this through and came to a solution that you like, but I want to note that there is a philosophical split among virtualenv users.

In one camp, to which, I believe, belongs to you, it is felt that the local VE is part of the project (i.e. it should be versioned). Another thinks that VE should essentially be seen as an artifact of development - that requirements.txt should be part of the repo project, but you should be able to deflate and recreate VE as needed.

I just mention this because when I first saw this difference, it helped shape my thinking about virtualenv. (I am in Camp Two, FWIW, because it seems simpler and cleaner to me, but this does not mean that being in Camp One is not suitable for your specific project.)

+9
May 16 '11 at 2:00
source share

In /lib/python2.7/site-packages in my virtualenv I have absolute paths, for example in Django.egg-link I have /Users/henry/.virtualenv/mowapp/src/django (this is a Mac).

Make sure you have absolute paths marked in git, I think this is a serious problem with this approach.

+2
May 14 '11 at 3:52
source share



All Articles