[CentralOH] virtualenv best practices for version control

Matthew Talbert ransom1982 at gmail.com
Fri Jun 10 19:04:52 CEST 2011

On Fri, Jun 10, 2011 at 8:37 AM, Mark Erbaugh <mark at microenh.com> wrote:
> If I have several non-related Python projects that use the same virtualenv setup should I create a separate virtualenv for each?  The obvious advantage is that if I need to update the virtualenv for just one of the projects, that change wouldn't affect the other projects. One disadvantage is setting up multiple identical virtualenvs.
> Is it possible to duplicate a virtualenv without rebuilding from scratch?  It looks like a several of the scripts in the bin directory have the top level directory hardcoded.
> What's the best way to keep track of the virtualenv setup when using version control on a project?  Ideally, I'd like to be able to check out the project and not have to worry about recreating the virtualenv. I suppose if there were only one project in a virtualenv, I could check the entire virtualenv into version control, but this still has the problem that it needs to be checked out into the same top level directory.
> If you do re-create a virtualenv when you work on an old project, should you be concerned about not being able to find the same version of a library online?  Do you include the library installers in version control, just in case?

We use Fabric to automate setting up a virtualenv. This is
particularly helpful when working on the same project with multiple
developers. You can add a file "requirements.txt" or something similar
that is used to install certain libraries (and even specific

Here's a relevant portion of our fabfile.py:

def create_virtualenv():
    local('virtualenv venv')

And a requirements.txt can look something like this:

-e git+git://github.com/django-mptt/django-mptt.git#egg=django-mptt
-e svn+http://django-photologue.googlecode.com/svn/trunk/#egg=django-photologue

I believe that requirements.txt is the default filename used by
virtualenv when it creates a new virtualenv, so if you don't want to
mess with Fabric, just adding this requirements.txt to your repo
should be sufficient, then you can just create the virtualenv with
"virtualenv [name]".


More information about the CentralOH mailing list