workingenv.py is a very useful tool for Python development. Quoting from its home page:

This tool creates an environment that is isolated from the rest of the Python installation, eliminating site-packages and any other source of modules, so that only the modules (and versions) you install into the environment will be available. This allows for isolated and controlled environments, as well as reproduceability.

To create, activate and deactivate an environment:

$ workingenv foo
$ . foo/bin/activate
(foo)$ deactivate
$

This is great, but what's even more so is using On Dir with it.

I need to work on multiple versions of Trac (stable, trunk, branches, etc.) at the same time, I have each version in its own directory beneath ~/projects/trac. Each Trac instance is completely self contained, so installing plugins in one will not affect the others.

So I use the following On Dir config to activate the workingenvs as I cd into each Trac directory.

enter ~/projects/trac/([^/]*)
    declare -F deactivate > /dev/null && deactivate
    activate=../env/$1/bin/activate
    test -r $activate && . $activate

leave ~/projects/trac
    declare -F deactivate > /dev/null && deactivate

Here's an example of me switching between environments. The last environment remains active until I leave the main Trac directory.

[aat@stalactite:~]cd projects/trac/trunk
(trunk)[aat@stalactite:~/projects/trac/trunk]cd ..
(trunk)[aat@stalactite:~/projects/trac]workingenv --site-packages ../env/stable
Updating working environment in /home/aat/projects/trac/env/stable
Installing local setuptools.................done.
(trunk)[aat@stalactite:~/projects/trac]cd stable/
(stable)[aat@stalactite:~/projects/trac/stable]cd ..
(stable)[aat@stalactite:~/projects/trac]cd trunk
(trunk)[aat@stalactite:~/projects/trac/trunk]cd ../..
[aat@stalactite:~/projects]

Of course, this can be extended to any project that needs its own independent Python environment, not just Trac.

I've arrived in Dallas for PyCon. I'm very keen, yes indeed.

A few Trac hackers will be attending, and we're getting together for a BoF and a sprint. I can't wait to finally put faces to the names of those on trac-dev :)

I'm still not 100% decided on what talks to go to. My experience at LCA made me painfully aware that the subject matter is only a small part of what makes a talk interesting, the delivery is just as important. I'm trying to keep that in mind when selecting talks for PyCon.

I'm hoping to keep a running commentary of my experiences here. Ostensibly for posterity but in reality because I've been roped into giving a run-down on it for SyPy, by Alan ;)

Now that 0.2 is finally out the door, what next?

Firstly, making query term negation work in the default indexer. Not having this is suboptimal. My initial thought on how to solve this will be to create a set class with support for lazily evaluated complements.

Next up, more extensive unit tests. Specifically, I want to test the UTF support of all the indexer adapters.

After many months of development, pyndexter 0.2 has been released. I'm much happier with the overall design of 0.2 than 0.1, although there are still some major features I'd like to add before I'm completely happy.