If you're doing any python programming at all, you're probably using virtualenv. If you aren't, this is the point at which you spank yourself. If you're using virtualenv, you might also have discovered virtualenvwrapper.

And if you're using virtualenvwrapper, there's a small little convenience you can configure to ease the workflow when you have more than one virtualenv to switch amongst.

Virtualenv will have a configuration directory (on my system, this is ~/.virtualenv) containing a lot of configuration files.

If you add cd $VIRTUAL_ENV to the postactivate file, then the command workon foobar will cd to that virtualenv.

If you add cd $HOME to the postdeactivate file, you'll cd back $HOME when you deactivate the virtualenv.

In related news, I need to figure out how to do inline preformatting in a drupal node...

I'm not going to translate the whole article, (if you're really that lazy, here's a google translated version), but the tl;dr is as follows:

Introduction

I have been using trac now to run a software aintenance and development project for a public sector client for over 2 years now. I work in one of the big Danish providers of IT and it's an area where this kind of job is normally done either by leviathans like HP Quality Center or BMC Remedy, or that other popular software lifecycle management suite, Microsoft Office.

It's a little atypical to be using trac in this environment. It doesn't cost 6 digits and it doesn't require several gigabytes of disk space, which probably disqualifies it from serious consideration more often than one would hope or believe. As mentioned above, other more "enterprisey" systems are prevalent in this area.

I chose trac for several reasons. The big one is that I know trac has such a huge userbase and community that the risk of serious problems is virtually non-existent. I also know python; this makes tacking any issues more feasible. trac is quite light and runs happily on a laptop; a third reason.

I'm clocking in eleven years of working with open source this year. Despite coming a long way in those years, it still appears to defy reason that the (often and not always) astronomically higher price/performance proposition of open source has not made it ubiquitous and the default choice. I don't believe in an open source software monoculture, but there is still too many examples of organisations acquiring expensive and inferior non-open source software when the technical and financial characteristics of the open source option were superior.