Django with PostgreSQL on Mac OS X Leopard

Originally posted Jan 20, 2008 · 3 min read

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 
&gt; LDFLAGS=-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib 
&gt; ./configure --with-postgres-libraries=/Library/PostgreSQL8/lib 
&gt; --with-postgres-includes=/Library/PostgreSQL8/include 
&gt; --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!