[CentralOH] virtualenv best practices for version control

Mark Erbaugh mark at microenh.com
Fri Jun 10 14:37:58 CEST 2011

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?


More information about the CentralOH mailing list