Django with PostgreSQL on Mac OS X Leopard

Previously, I discussed the steps I went through to get PostgreSQL
working on Tiger
. This weekend I upgraded my system to a new MacBook
Pro running Leopard.

PPC -> x86

Although the Migration Assistant copied the version of PostgreSQL I
had previously installed to the new machine, the results didn’t work
because the service would not start correctly. I ended up reinstalling
using the Unified Installer from PostgreSQL for Mac, and the server
still wouldn’t start. I deleted the old database and re-initialized it
(thanks to hints in some instructions from Russell Brooks) and that
took care of the problem. I’m not sure if there was any way for me to
convert the data, but I didn’t have anything important in the database
that I can’t re-create, so it’s fine to start from scratch.

X Code

The next step was to install X Code 3. That was easy, with the package
installer from Apple.

psycopg

And then I went back to battle with my old nemesis psycopg. I should
probably have taken Steve Holden’s advice in the comments on my earlier
post and just used psycopg2 instead. I didn’t because that would have
meant upgrading my production server, too, since the whole point of
using PostgreSQL instead of SQLite is the back-end adapters in django
produce different SQL for the same QuerySet.

To configure psycopg, I had to set LDFLAGS to include the directory
with the crt1.10.5.0 library. It’s installed to what looks like
should be a standard library directory for the X Code gcc, but ld
couldn’t find it during the “create an executable” test.

Then when running make I had the same problem I had seen under
PPC:

$ make
gcc  -DNDEBUG -g -O3  -I/Users/dhellmann/Devel/AthensDocket/bin/../include/python2.5
-I/Users/dhellmann/Devel/AthensDocket/bin/../lib/python2.5/config -DPACKAGE_NAME="psycopg"
-DPACKAGE_TARNAME="psycopg" -DPACKAGE_VERSION="1.1.21" -DPACKAGE_STRING="psycopg 1.1.21"
-DPACKAGE_BUGREPORT="psycopg@lists.initd.org" -DHAVE_LIBCRYPTO=1 -DHAVE_ASPRINTF=1
-I/Library/PostgreSQL8/include -I/Library/PostgreSQL8/include/postgresql/server
-I../egenix-mx-base-3.0.0/mx/DateTime/mxDateTime -DHAVE_PQFREENOTIFY -DNDEBUG -D_REENTRANT
-D_GNU_SOURCE -DPOSTGRESQL_MAJOR=8 -DPOSTGRESQL_MINOR=2   -c ././module.c -o ./module.o
In file included from ././module.c:33:
././module.h:30:20: error: Python.h: No such file or directory

I thought this was related to using virtualenv, but it didn’t work
correctly outside of the virtualenv setting this time (for some reason,
it did on the PPC laptop). It turns out the error message was correct
and configure/gcc just couldn’t tell where the Python headers were. The
configure command that let me compile was:

$ CPPFLAGS=-I/Library/Frameworks/Python.framework/Headers 
> LDFLAGS=-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib 
> ./configure --with-postgres-libraries=/Library/PostgreSQL8/lib 
> --with-postgres-includes=/Library/PostgreSQL8/include 
> --with-mxdatetime-includes=../egenix-mx-base-3.0.0/mx/DateTime/mxDateTime

Then, oddly enough, when I did my make install step, the
psycopg.so was copied to $VIRTUAL_ENV/bin instead of
$VIRTUAL_ENV/lib/python2.5/site-packages. That was easy enough to
solve by moving the file manually, and then I was able to import the
psycopg module.

So, after about an hour, I’m back to being able to develop with django
and PostgreSQL on OS X Leopard. Maybe now I can start enjoying some of
the new features!