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

Question

I currently have git and virtualenv set up in a way which exactly suits my needs and, so far, hasn't caused any problems. However I'm aware that my setup is non-standard and I'm wondering if anyone more familiar with virtualenv's internals can point out if, and where, it's likely to go wrong.

My setup

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 working on a checkout of the project -- can use virtualenv and pip as normal but with the following advantages:

1. If anyone updates or installs a package and pushes their changes, anyone else who pulls those changes automatically gets the update: they don't need to notice that a requirements.txt file has changed or do any post-receive hook magic.

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

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

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

Answer 1

This is an interesting question. I think the other two answers (thus far) raise good specific points. Clearly you've thought this through and have arrived at a solution you like, but I'll note that there does seem to be a philosophical split here among virtualenv users.

One camp, to which I'd guess you belong, feels that the local VE is part of the project (ie it should be under version control). The other feels that the VE should essentially be treated as a development artifact -- that requirements.txt should be part of the project repo, but that you should be able to blow away and recreate the VE as needed.

I just mention this because when I first saw this distinction made, it helped shape my thinking about virtualenv. (I'm in the second camp, FWIW, because it seems simpler and cleaner to me, but that's not to say that being in the first camp is wrong for your particular project.)

Answer 2

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

Answer 3

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

Check to see if you have any absolute paths checked into git, I think that is a major problem with this approach.