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

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!