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 Unix variants) 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.