You are here: Home Blog Creating a Python 2.4, Plone and Zope Development Environment on Mac OS X Leopard

Creating a Python 2.4, Plone and Zope Development Environment on Mac OS X Leopard

by Dan Fairs last modified May 07, 2008 04:49 PM
Compiling Python, Zope and Plone on Leopard isn't as easy as it is on Linux. Here's a walkthrough of the process, from a bare Leopard install right through to having a working Plone 3 development environment, using paster and buildout.

UPDATED 27/01/2008: Added instructions on building PIL with buildout

If you're new to Zope and Plone on the Mac, and just want to get up and running, stop reading right now! Instead, go and download the unified Plone installer for Mac OS X, Linux and Solaris on Plone.org. This article is for people who need more control over the installation, and need to build the core pieces from source.

Still reading? Good.

Note that the information here has been drawn together from a number of places on the web. However, it's not been presented as an end-to-end process. That's what I aim to do here.

Install development tools

Development tools (compilers and headers, basically) aren't installed by default on Leopard. Dig out your Mac OS X DVD, and install Xcode. This will give you everything you need. You should be able to do something like this:

$ gcc
i686-apple-darwin9-gcc-4.0.1: no input files

You can see that the gcc compiler is installed. If instead you see 'command not found', then you don't have gcc installed.


Compiling Python

Python is the first hurdle. Leopard ships with Python 2.5, but Zope 2 still requires 2.4. Unfortunately, Python 2.4 doesn't compile out of the box with Leopard. You'll see something like this:

hornet:Python-2.4.5 dan$ ./configure --prefix=/Users/dan/tmp/opt
[snip lots of output]

hornet:Python-2.4.5 dan$ make
[compile, compile, explode]
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE  -c ./Modules/signalmodule.c
-o Modules/signalmodule.o
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c
-o Modules/posixmodule.o
./Modules/posixmodule.c: In function 'posix_setpgrp':
./Modules/posixmodule.c:3145: error: too few arguments to function 'setpgrp'
make: *** [Modules/posixmodule.o] Error 1

Ouch.

Fortunately the solution for this is actually on the Python.org site. (If you scroll down a bit, which I didn't initially). Simply modify your configure line to include an extra define:

./configure MACOSX_DEPLOYMENT_TARGET=10.5

You should fine Python now compiles. You can then make install.

Oh - but the fun isn't over yet! Have a play with your new Python. At best, you'll find your arrow keys don't work. At worst, you'll experience odd crashes with the helpful generic Bus Error message.

Fortunately, Andreas Jung has the answer here: a broken or outdated version of the readline library. You can compile your own, or do what Andreas recommends and install one from DarwinPorts. Once that's installed, you simply need to do:

$ sudo port -d selfupdate
$ sudo port install readline

You should now have a working readline. Next up, you need to configure your Python build environment to pick this up (otherwise it'll just pick up the broken OS X readline again.) I actually did this the way Andreas describes, a manual hack in the Makefile:

CC = gcc -I/opt/local/include -L/opt/local/lib

I suspect that you'd be able to pass --includedir=/opt/local/include and --libdir=/opt/local/lib to the configure script, and that would be a cleaner way of doing it. Once you've down that, run make and make install, and you should have a working Python, with working readline support, that doesn't crash.

Remember to set your PATH up to use your new Python binary in preference to the system one - something like:

export PATH=/Users/dan/opt/bin:$PATH

What's next?

setuptools

A lot of stuff these days is installed using setuptools. Download ez_setup.py to somewhere convenient, and run it using your new python:

python ez_setup.py

This will download and install setuptools into your Python 2.4's site-packages directory, and configure it so that it's usable.

To check it's installed correctly, type:

which easy_install

The path should be within your Python 2.4 install. If it's not then you've managed to install it into your system Python. First - why are you running as root; and second, check your PATH.

Note that from now on we're going to be using a package called virtualenv to isolate any further package installs. You've gone to a lot of effort to get a working 2.4 install - let's keep it tidy!

virtualenv

virtualenv is a fantastic tool which creates a Python 'sandbox' to work in. This means that you can install packages in a virtualenv to your heart's content, and it won't pollute the main Python installation. It creates a new python binary, and lib/python24/site-packages structure to facilitate this.

Installing it is dead easy:

easy_install virtualenv

virtualenv will be downloaded and installed. Let's immediately create a virtualenv to work in:

$ mkdir -p ~/virtual/2.4
$ cd ~/virtual/2.4
$ virtualenv plone3
New python executable in plone3/bin/python
Installing setuptools............done.
$ cd plone3
$ source bin/activate
(plone3)$

Note how your prompt has changed - this is a visual clue that you're now working in a virtual environment. Look at the output for:

which python

You should see that the Python from the virtualenv is used. This of course means that any further easy_installs you do will be into thsis virtualenv.

As above, I find it useful to put my virtualenvs for Python 2.4 and Python 2.5 in separate directories. But that's just me - running source bin/activate in each virtualenv will do the right thing.

ZopeSkel

ZopeSkel is a package which will install paster, buildout, and some commands to help create Plone development instances (amongst other things, including Silva instances, Plone themes, etc.) Installing it is easy:

 (plone3)$ easy_install ZopeSkel

This will whir for a while. Once it's installed, you should find that you have a paster installed:

which paster

... will show you that it has, as with everything else, been installed into your virtualenv.

Creating a Plone 3 development environment

We're on the final leg of the journey now!

paster and buildout do most of the heavy lifting for us here. First of all, we use paster to create a buildout for us:

paster create -t plone3_buildout p3

This, again, will whir for a while. plone3_buildout refers to the template to be used to create p3. If you're interested, you can see what other templates were installed:

paster create --list-templates

Of course, paster create --help will give you more information on available options.

PIL

Before we run our buildout, we need to install the Python Imaging Library, also known as PIL. Previous versions of this article described how to download and install this from source. However, there is now an easier way.

Edit the p3/buildout.cfg file and edit it as follows:

[buildout]

parts =
  PIL
  ....

eggs =
  ...
  PIL

[PIL]
recipe = zc.recipe.egg
egg = PIL==1.1.6
find-links = http://dist.repoze.org/


Building Zope and Plone

Now we have our buildout, we're ready to go. Let's finally build Zope out, configured for Plone. During this process, you'll be asked for an initial administrative username and password for Zope:

(plone3)$ cd p3
(plone3)$ python bootstrap.py
(plone3)$ bin/buildout

Now go and make a cup of tea - that last step can take a while.

What's happening is that buildout is using the buildout.cfg to locate and download all the eggs and parts which make up a Zope 2 and Plone 3 installation. It will then compile and install those for you. If you run buildout with multiple -v options (eg. -vvvv) then it'll give you a lot more information about what it's doing.

When this finishes, you should be able to run up your Zope instance:

(plone3)$ bin/instance fg

Browse to http://localhost:8080 (assuming you kept the port the same) and you should see the familiar Zope Quick Start page.

Creating a development egg

It's likely that all new development that you'll be doing in Plone 3 will be egg-based. However, it's not immediately obvious how you get started.

Development eggs live in the src/ directory of your buildout. As with the main Plone 3 buildout, we use paster to create the egg for us:

(plone3)$ cd src/
(plone3)$ paster create -t plone egg.name

You'll get asked some questions. The namespace and package you should set appropriate for your project (I'll assume you answered 'egg' and 'name' respectively); and say 'no' to the Zope 2 product and zip-safe questions. Paster will then go ahead and create the file structure for your egg in src.

Finally (and I mean it this time) we have to tell buildout about the development egg. Go back up one level of directory, above src, and you should see a file called buildout.cfg. Edit this file, and add the following:

[buildout]
eggs =
    egg.name
...
develop =
    src/egg.name
...
[instance]
zcml =
    egg.name

Once this is saved, then run buildout again in offline mode:

bin/buildout -o

This will look at your buildout.cfg and modify the buildout to include your development egg.

And after that?

If you've got to here, well done! You've now got a development environment. The final stage, once you've developed your egg, is to package it. This is pure setuptools. From within your egg:

python setup.py sdist bdist_egg

This will create a finished egg, placed in the dist/ directory, ready to use. It will also create a source distribution (ending in .tar.gz).

There's a lot more to learn around this process - but I hope that's clarified the basic procedure, and workarounds for some of the issues specific to Mac OS X Leopard.

Filed under: , , ,
Chris Calloway
Chris Calloway says:
Feb 23, 2011 10:54 PM
Just in case anyone is still referring to this article (i.e., trying Python 2.4/Plone 3 buildouts on OSX 10.5), the latest MacPorts readline and the latest Xcode for 10.5, which have changed since this article was posted, will now require this to work:

./configure MACOSX_DEPLOYMENT_TARGET=10.5 LDFLAGS=-L/opt/local/lib OPT=-I/opt/local/include

Hacking the Makefile or using --includedir and --libdir no longer are enough.

This article gets returned pretty high in search results, so I thought I'd pass this along. Thanks for this article. It has helped a lot of people.
Add comment

You can add a comment by filling out the form below. Plain text formatting.

Stereoplex is sponsored by Fez Consulting Ltd