I'm pleased to announce that Foundry's first web site has gone live: Swoop Travel.

Swoop Travel is a GeoDjango site using PostgreSQL and PostGIS, although very little GIS functionality is in the public-facing site at the moment - it's mainly in the backend.

We built this from scratch in about a month (while juggling other projects too!) are are pretty pleased with how it's turned out. This is just the first iteration and we're looking forward to expanding the site.

GeoDjango is pretty awesome. As we work on the site and get more experience, I'll post some more about some of the innards: there's quite a lot of interesting stuff in the backend, particularly admin customisations like filtering dropdowns based on landmarks within geographic regions, and so on. I'll also try to talk about the production server configuration, as GeoDjango needs a slightly different WSGI configuration to the standard run-of-the-mill Django site.

I managed to mess up a PostgreSQL install on my Mac, which (somehow) left the postgres user account with an invalid home directory. Fixing this took quite a bit of digging.

First, launch the 'dscl' command as an administrator (probably with sudo). This drops you at a prompt, where familiar commands like cd, ls, cat and so on work. So, to change the user's home directory, I did:

 
bash $ sudo dscl
> cd /Local/Default/Users
/Local/Default/Users > ls
... user list ...
nobody
postgres
/Local/Default/Users > cat postgres
AppleMetaNodeLocation: /Local/Default
NFSHomeDirectory: /Users/dan/opt/pgsql
Password: *
PrimaryGroupID: 1
RealName: PostgreSQL
RecordName: postgres
RecordType: dsRecTypeStandard:Users
UniqueID: 504
UserShell: /bin/bash
/Local/Default/Users > change postgres NFSHomeDirectory /Users/dan/opt/pgsql /usr/local/pgsql
/Local/Default/Users > q
Goodbye
bash $

After that, the postgres user had a valid home directory, and all was well with the world.

Sometimes, I see the following error when trying to run a Django buildout:

File "/Users/dan/.eggs/djangorecipe-0.20-py2.6.egg/djangorecipe/recipe.py", line 271, in install_release
    os.listdir(extraction_dir)[0]
OSError: [Errno 2] No such file or directory: '/Users/dan/.downloads/django-archive'

After a bit of poking around, I found that this is to do with a corrupted Django tarball. In my case, this is usually because I've interrupted a download with Ctrl-C. Unfortunately it seems that the tarfile module in the Python standard library (at least as invoked by setuptools) treats broken a tar.gz files as an empty archive, without throwing an exception. Since there's no exception, djangorecipe assumes everything was uncompressed without problems, and is therefore rather surprised when the unpacked Django package isn't where it expected it to be.

The short term solution is to delete the bad Django archive from your download cache. This will likely be a 'downloads' directory in your buildout, or you may have a global one (as I do). When you next run buildout, the tarball will be freshly downloaded.

When I get a moment I'll see if I can modify djangorecipe to notice this condition and not proceed with the build.