Building and installing the GDAL/OGR Python bindings can be a bit of a pain in the neck. It's complex software with a lot of associated data. At the Lab, we're using zc.buildout (see pcl.buildout for a specific example) to create replicable, version-controlled Python environments that include GDAL/OGR (as well as MapServer and PostgreSQL + PostGIS).
Another new option for deploying intricate environments is Ian Bicking's virtualenv. From the readme:
virtualenv is a tool to create isolated Python environments.
The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.4/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.
Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.
Also, what if you can't install packages into the global site-packages directory? For instance, on a shared host.
In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't use the globally installed libraries either).
Virtualenv covers the same ground as the GDAL project's FWTools, but is more programmable and customizable. It integrates with setuptools, and so getting a fresh Python GIS environment from the package index could be just as easy as:
$ sudo easy_install gdal-env
Of course, someone would have to actually create and upload that gdal-env package. Bicking advises us to switch from workingenv to virtualenv.
I've written to the geo-web-rest group about CouchDB, a distributed, non-relational database, and now Sam Ruby has a Python prototype. Basura uses some elements that I like to blog about: namely JSON and WSGI.