After reading Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip I updated my current Python project to take advantage of some of the techniques described. Some of the most important methodologies that developers can employ are isolation and automated duplication. Virtualenv makes it easy to isolate and run different programs using different Python and library versions on the same machine. When it comes to duplication, pip makes it a snap for a developer to recreate another developer's frozen environmnent. I'll just briefly explain how I've used these tools.
Pip and virtualenv, the two tools that make Python time travel possible, were written by Ian Bicking and there's more information available on his blog post about pip requirements. They make it very easy to specify the exact library versions a project requires. From inside your project directory, it's as easy as:
easy_install virtualenv pip
virtualenv . --no-site-packages
pip -E . install [libraries your project requires, such as ipython]
# For example, when sandboxing my blog, I ran `pip -E . install weblog`
source bin/activate # this puts your shell into the sandbox
# make sure your program works here
pip -E . freeze > requirements.txt
--no-site-packages makes the environment a sandbox so it doesn't rely on any packages already installed on your system. I highly recommend always using this setting to get the full benefit of virtualenv. "-E ." tells pip to use the environment in the current working directory. You can add the requirements.txt to version control. It's also a good idea to tell your version control system to ignore bin, docs, src, include, man and lib directories that are created by virtualenv.
The generated requirements file looks like this for my blog:
Jinja2==2.1.1
markdown2==1.0.1.13
weblog==2.1
wsgiref==0.1.2
And it looks like this for dongsa.net:
CherryPy==3.1.2
Jinja2==2.1.1
coverage==3.0.1
-e git://github.com/dbravender/gp_through_unit_tests.git@7b2625470f08e033cd0c562129ce8592da08eadf#egg=gp_through_unit_tests-0.1-py2.6-7b2625470f08e033cd0c562129ce8592da08eadf
nose==0.11.1
wsgiref==0.1.2
As you can see, pip has support for downloading and installing packages from version control systems such as git.
Later, the sandbox can be recreated like so:
virtualenv . --no-site-packages
pip -E . install -r requirements.txt
There are still some rough spots when it comes to pip and virtualenv. One noticeable problem that Jesse Noller pointed out is that the interpreter path is hardcoded at the top of every file so you can't easily move these environments around. This is pretty easy to work around, just reinstall the environment or write a simple sed script (like Jesse mentions) to update the hardcoded paths.
I'm going to get busy updating my other Python projects (especially my work projects) so other developers can easily recreate a working environment and not waste any time getting cryptic errors because I forgot to mention a particular library in the README.