[CentralOH] virtualenv best practices for version control
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:
And a requirements.txt can look something like this:
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
More information about the CentralOH