virtualenv

A couple of days ago, Chris posted about using virtualenv to create sandboxes on Leopard instead of installing packages directly into the Frameworks directory. I’d heard of virtualenv, but never tried it before. After reading what Chris said, I downloaded it and gave it a try, and have to say, “Wow!”

I had been worried about installing a ton of dependencies on my system so I could test code associated with articles submitted to Python Magazine. I planned on setting up a VM, so I could at least isolate that code from my own development environment, but virtualenv is going to be much easier to deal with. I can create a separate environment for each article, and verify the dependencies as necessary.

When you run virtualenv, it sets up a fresh sandbox version of Python by copying/linking files from your default installation to create new bin and lib directories. It does not copy site-packages, so you have a clean place to install any packages you want (with easy_install, or by other means). It does include your default installation in the PYTHONPATH for the new sandbox, so you can use modules already installed there as well as anything you install into the sandbox.

The new sandbox also includes a simple script to activate/deactivate the environment for your current shell. When you activate an environment, your command prompt changes (at least under Mac OS X, and I assume other Unixen) to remind you that you’re using that environment, and your PATH is automatically updated to use the new bin directory. You can also run the interpreter from the environment directly, without “activation”, and it knows to look for modules using the correct path.

I’ll probably still set up that VM, but I know I’ll worry a lot less about conflicts between different modules as I test the code from our authors.


Technorati Tags:
,


  • http://www.blogger.com/profile/13609779138164842374 Graham Dumpleton

    It may not copy ‘site-packages’, but as you say, it still sets things up to look there. In some cases this may not be what you want as you may not want a package in the system Python ‘site-packages’ to be visible at all from the virtual environment. If you want a truly clean environment, use the ‘–no-site-packages’ option to ‘virtualenv’ and then it will not even refer to the system Python ‘site-packages’ directory.

    Also, not using ‘activate’ is not a good idea when installing packages using custom scripts which in turn install further packages. This is because some scripts expect to find ‘easy_install’ in your PATH, but if you don’t use ‘activate’, then it can still find that in the system area and additional packages will be installed there instead of the virtual environment.

  • http://www.blogger.com/profile/01892352754222143463 Doug Hellmann

    Thanks for the tip about ‘–no-site-packages’, Graham, I can definitely envision cases where the clean environment might be preferred and that option will come in handy.

    And the warning about not using activate is well taken.

  • http://www.blogger.com/profile/00681417666810836282 lcaamano

    You might also want to take a look at Martin’s post at

    http://tinyurl.com/ystbaf

    http://martinaspeli.net/articles/python-package-management

  • http://www.blogger.com/profile/01892352754222143463 Doug Hellmann

    @lcaamano – I had a brief glimpse of buildout at a recent PyATL meeting where the presenter used it to install Zope and Plone during the presentation. It definitely solves the repeatability problem, but (perhaps due to the association with Zope) it seemed complicated. I didn’t realize it was usable with non-Zope projects, so I’ll have to give it another look.