Programmers and Practice vs Training

Lately I've been trying to learn one new thing every day.   And one of the sad discoveries that I've made is that I'm capable of forgetting things almost as quickly as I learn them.

So, two months after I learned how to write vim macros - I've already forgotten the specific keys used to define and run them.   Now, I can re-learn this very quickly - I've got good notes, the memories are just slightly hidden, and I haven't forgotten any concepts, just simple keys.   But this will slow down my use enough that I probably won't pull this tool out when I need it.

This got me thinking about how I needed to complement training with some  some repetition, some practice.   That just learning something isn't good enough.   This is exactly what martial artists do - they would call these katas.    It's also what musicians do - they would call these scales.


Working With Multiple Environments in Python

Working within a single Python environment in which you're limited to a single version of python and a single version of all your modules is fine for small projects, but as the number of projects or age of projects increase it leaves you boxed in.  You can't test your software against a new version of a dependency without putting everything else on hold, and then you may have to revert back.  Eventually, you'll end up doing insufficient testing or spending far too much time on installing, uninstalling, and developing projects in series rather than parallel.

Ian Bicking's Virtualenv changed this in 2007 with the ability to create multiple environments for a Python application.  Then a year later Doug Hellman wrote Virtualenvwrapper which added a set of convenience functions that significantly enhance virtualenv.

The documentation for these products is generally very good, but it seems to me that something is missing - documentation that pulls everything together across products so that the beginning user has a simple recipe for success.  The closest would be The Hitchhiker's Guide to Python, but this doesn't address multiple Python versions.   And I really want to nail down how to do this with multiple versions of Python.

The following information is intended to be a first step in that direction for the linux developer.


Working With Multiple Versions of Python

I've needed to run multiple python versions for a while now, and have finally bitten the bullet and invested the time to get this working.    The primary drivers of this need are two separate projects:
  • At my office we're running Redhat Enterprise Linux 5.8 which uses Python 2.4.  We've got an alternate install of Python 2.6 available, but I'd like to move immediately to Python 2.7 and in six months to Python 3.3.   During the transition I may have some components running on one version and others running on another.   This will help me incrementally move over.
  • One of my side projects, DataGristle, was written on Python 2.6, but is being used on Python 2.6 & Python 2.7 environments.   Testing it to ensure it works correctly on both previously required a second machine.   I'm getting tired of that and looking forward to eventual Python 3.1, 3.2, 3.3 compatibility.
But I've discovered that the documentation for this seems to only exist in bits and pieces distributed around the net.  The closest would be The Hitchhiker's Guide to Python, but this doesn't address multiple python versions and doesn't generally have command-by-command configuration instructions. The following information is intended to help put together a complementary, consolidated recipe to make this easier for a beginning Python developer on linux.

So, this is the first of two series about working with many environments.  The second series is about Working with Multiple Environments.

I've been updating these articles as update (aka corrections) are coming in, and experimentation with clean environments via VirtualBox slowly moves forward.  Thanks for the corrections and patience.