workingenv revisited

I did some work on the script I mentioned previously for setting up environments (as an alternative to virtual-python.py. I also moved it slightly, to http://svn.colorstudy.com/home/ianb/workingenv

It now plays nicely with Setuptools. Well, maybe that's an exaggeration; at least the two are talking again.

Here's the way it basically works:

$ wget http://svn.colorstudy.com/home/ianb/workingenv/workingenv.py
$ python workingenv.py new-environ/
$ source new-environ/bin/activate

Now everything you do will use the libraries installed in new-environ/ (and no other libraries!), and new libraries will be installed into that location (until you deactivate). Any scripts installed will go in the new-environ/bin/ directory, and (at least if you are using Setuptools) will implicitly activate the environment whenever they are invoked. The explicit activation should (hopefully) only be necessary during development.

activate doesn't do anything fancy, just update $PYTHONPATH to include new-environ/lib/python2.4. Setuptools doesn't need to be installed (if it isn't, it will be installed for you). It should work with Python 2.3, but probably not earlier.

I also added a notion of a requirements listing for a new environment, basically a list of packages to be installed. Admittedly this is only loosely related to the installation. But anyway, you can use this to quickly set up a nice fresh environment. Since the TurboGears people have been thinking about this some (though admittedly I haven't read through the discussion) I threw together a couple half-assed examples for 0.8 and 0.9. It goes like:

$ python workingenv.py -r \
  http://svn.colorstudy.com/home/ianb/workingenv/tg-example.txt \
  new-environ/

This reads that text file, gets requirements out of it (including a --find-links setting), and installs everything. The advantage of this is that the requirements listing isn't associated with any one package. It can have highly constrained requirements (i.e., exact versions), but this doesn't cause a cascade of changes when a single package is updated. Also, the requirements are only checked at installation, they aren't checked at runtime, so you can manually install other versions for testing and development without getting conflicts.

Thanks for updating this Ian! I'm now a convert from virtual-python :)

I can confirm that the new workingenv.py works on OSX 10.4 using the latest Universal Python.

I get this error when I run "workingenv.py working-env" though:

$ workingenv.py working-env
Making working environment in working-env
...
Creating file bin/activate
Creating file lib/python2.4/setuptools/__init__.py
Overwriting file lib/python2.4/site.py
Installing
error: No urls, filenames, or requirements specified (see --help)

It appears to only act as a warning though since everything else works fine.

Also, a nice little shortcut I use in bash for "source working-env/bin/activate" is ". working-env/bin/activate"

It was trying to install things even when you didn't ask (with --requirements). Fixed now, thanks. I also made the script a bit quieter.

Here's another typing-reduction hack I did:

Created a directory env in my home directory.

Added this to .profile:

function activate {
    source $HOME/env/$1/bin/activate
}
export activate

Now I use "working-env.py ~/env/foo" to create the "foo" environment, and whatever path I am in I can run "activate foo" to activate that environment.

Found a wart, figured this was the best place for it :)

If you have a working environment, and you install certain packages, such as roundup, using python setup.py install, the install process places packages in $ENV/lib/python2.4/site-packages instead of directly in $ENV/lib/python2.4 which seems to be the intended place for installed packages when using workingenv.

Quick solution that I used:

Add a sitepackages.pth file to $ENV/lib/python2.4 that has one line:

site-packages

Thank you, this is very handy!

What is the best way to link to other, non-egg python packages (like standard site-packages directory)? I am having problems with easy_install(ing) psycopg for instance, which is already installed at the standard location.

Ian Bicking: the old part of his blog

workingenv revisited

Comments: