Once we have mod_wsgi configured, the server is finally ready for Repoze. The first step is to create a new Repoze sandbox. Since Repoze, Zope and friends require lots of packages, the idea is to get a clean environment for your project, where packages do not conflict with existing or future packages from your normal Python installation. We use setuptools to install the virtualenv package:

$ easy_install-2.4 virtualenv

 When virtualenv is ready, we create the actual sandbox. Choose a directory where you would like to install the Plone sandbox and pass it to virtualenv like this:

$ virtualenv --no-site-packages /path/to/sandbox

The --no-site-packages option ensures that the new Python installation does not inherit any packages from the normal installation. After this is done, we finally install Plone using a specially packaged egg from the repoze.org repository. Right now, since Plone is not packaged as a collection of eggs, this is the only place where we can get that. Sadly, this means that until the Repoze crew gets around to creating a new egg, we are limited to Plone version 3.0.1. In the future, Plone may be packaged in a usable manner and we could then use plone.org as a repository, thus getting the latest official release. For now, we have to do this:

$ /path/to/sandbox/bin/easy_install -i http://dist.repoze.org/simple repoze.plone

This command was run using my regular user account and created a plone directory which is actually the Repoze sandbox. The repoze.plone egg that installs this also installs a few sample configuration files, which may be used almost "as is" to run the new site. Be warned that distutils tries to byte-compile all python files it finds at install time, which means the Python scripts under Plone's skin directories will throw some syntax errors, since they are not always valid Python code. You can safely ignore these errors.

The last thing that we need to do is to create the Zope instance for our Plone site:

$ /path/to/sandbox/bin/mkzope2instance .

This will create all of the required configuration files and directories for a Zope instance. The most important files are located on the etc directory of the sandbox:

• 'zope.ini', a Paste configuration file used to establish the Paste (WSGI) pipeline which repoze.zope2 will use to serve up repoze.zope2.
• 'zope.conf', a classic Zope 2 configuration file which can be used to adjust Zope settings.
• 'site.zcml', a boilerplate site.zcml that should be used to control ZCML processing.

To test the installation, first it is needed to add a new user to the Zope site. The command is run from inside the sandbox directory:

$ bin/addzope2user cguardia password

Now the site could be tested using paster:

$ bin/paster serve etc/zope2.ini

Once this is run you will have access to the newly installed Zope site at port 8080. It's a good idea to take advantage of this test to add a Plone Site inside, so everything is ready for the WSGI configuration.

The only other requirement for running under mod_wsgi is to install a ZEO server and modify the sandbox's etc/zope.conf file to use a client storage pointing to it. This is very easy, just run (inside the sandbox):

$ bin/mkzeoinst .

This creates runzeo and zeoctl scripts under the bin directory. Since mkzeoinst doesn't delete existing files, it's important to make sure that they don't exist before running it.

Now you need to set up a ZEO client or more. Here is a sample configuration stanza for one client, which should be added to the zope.conf file:

<zodb_db main>
    cache-size 5000
    <zeoclient>
        server localhost:8100
        storage 1
        cache-size 20MB
        name zeostorage
        var $INSTANCE/var
    </zeoclient>
    mount-point /
</zodb_db>

That's it. The site is now ready to work behind Apache and mod_wsgi.

$ bin/zeoctl start
$ sudo apache2ctl start

There it is. Zope can now run directly behind the Apache server, without need for its own ZServer. As you can see, using Repoze, Zope and Plone can now coexist peacefully with other Python frameworks using WSGI.