I've been using workingenv more lately, and I thought I'd talk more about its goals.

If you haven't used it, or didn't read/remember the original post, the basic idea is that you do this:

$ wget http://svn.colorstudy.com/home/ianb/workingenv/workingenv.py
$ python workingenv.py NewEnvironment
$ cd NewEnvironment
$ source bin/activate

This creates an isolated environment in NewEnvironment/ that contains its own libraries isolated from the rest of the system. As such it is very similar to virtual-python.py but perhaps slightly simpler, in that it doesn't create a new python executable or symlink over the entire standard library. Honestly virtual-python works quite well too, though I suppose workingenv works on Windows (without symlinks); at least, I hear it does, I've never tried it.

This is great for tutorials and examples, since the result is a very controlled system. It's common for people to forget that they have all sorts of hidden requirements installed on their system, and since workinenv removes all of those libraries (including everything in site-packages unless you give the --site-packages option) you won't forget anything. It's very repeatable.

There's some other features lingering in workingenv that might be additionally useful. In particular --requirements, which lets you give a set of requirements to be installed by easy_install when the environment is set up (you can also track the requirements over time to confirm you are up-to-date). For instance:

$ python workingenv.py \
  --requirements=https://svn.openplans.org/svn/training/pylons/requirements.txt \
  NewPylonsEnvironment

This is the Pylons environment we used for the a mini-tutorial in the framework at TOPP. If you look at the file, it's just a text file with one requirement per line. You can also use -f someplace_to_find_links, which will in effect add that option to all subsequent easy_install invocations. Pylons has such a page at http://pylonshq.com/download/, TurboGears at http://www.turbogears.org/download/, etc. And -e Package to install an editable version of a package, which you can use for all your internal/in-development packages. Later on you can rerun workingenv.py to update the environment and requirements, or run workingenv.py --confirm NewPylonsEnvironment/ to check if anything has changed in the requirements file, or any requirements aren't in sync.

Some other things I'd like to add:

• Show all libraries that are installed but aren't required by any requirements file (either detecting dependencies that should be added, or packages that aren't needed and should be deleted).
• A command to include libraries from the system site-packages/ into the environment. This is useful for libraries that might be hard to build in the new environment, like MySQLdb.
• A command to build a requirements file from the current state of the working environment. Then you could build up a working set and come up with a succinct description of that set. An option could make it very specific (with exact versions, suitable for deployment), and flexible (with the most recent versions, suitable for development).
• If anyone knows a way to avoid hardcoding a full path in bin/activate, I'd love to know. That's the only place where the full path is coded in, so other than that the environment can be safely moved around.

Notably another project with some similar goals is zc.buildout. zc.buildout is more declarative, and works off a configuration file instead of interactive commands. For example, you install something something in a buildout by changing the configuration and rebuilding. You install something in a working environment by using easy_install. zc.buildout is also more general -- it has recipes to do more than just install eggs, it can also build packages with configure; make; make install (cmmi), and you can add new recipes for more complicated setups. I've found it more difficult to get my head around, especially how to support both production and development deployments. But if you are interested in this sort of thing, you should certainly give it a look (I've noticed it already has considerably more documentation than when I last looked).