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
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 (i.e. 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.)
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!
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.