Daniel Nouri's Blog

Create a pristine Zope instance

ploneenv $INSTANCE_HOME -m $MKZO --no-requirements

source $INSTANCE_HOME/bin/activate
easy_install yolk

yolk -l

Create an instance with Plone 3 from Subversion in it

easy_install Plone==dev

Create an instance with a Plone 3 release in it

ploneenv $INSTANCE_HOME -m $MKZO

Develop packages for Plone 3

easy_install ZopeSkel
paster create -t plone mypackage

source $INSTANCE_HOME/bin/activate
cd mypackage
python setup.py develop

Status quo

Plone 3.0, ploneenv and the Plone egg distribution are under heavy development still. Therefore you might encounter errors while trying out these recipes. Please report those!

There is one known problem with ploneenv, where easy_install attempts to compile Script (Python) files and spews a lot of error messages. However, those error messages are not critical, and the installation succeeds nevertheless.

If you're developing Plone 3 itself, you might want to go for ploneout, which is the mechanism used by most Plone developers who actively develop Plone.

My previous blog on ploneenv has some more pointers and info.

Update: Thanks to Paul Everitt, there is now a ploneenv screencast.

What is ploneenv?

ploneenv builds a Zope instance that is also a workingenv and installs (by default) Plone 3.0 in it.

There are other packages out there that can do the same:

• ploneout
• instancemanager
• zopebuilder (anyone have a link?)
• skeletor

The most prominent of these packages is ploneout, a Zope Buildout configuration (including add-ons) that allows you to install Zope and Plone 3.0 in one step. While this is a very appealing solution in most situations, sometimes it is more comfortable for a developer to work more interactively, in an environment where packages can be installed and tested out, removed, replaced and queried using the standard easy_install and tools like Yolk.

So what is ploneenv? ploneenv is a one module Python script that builds heavily on workingenv and setuptools. What it does:

• It creates a Zope instance for you. You always provide the mkzopeinstance.py script that you want to use as an argument. E.g.:

  ploneenv ~/myzopeinstance --mkzo=~/lib/Zope-2.10/bin/mkzopeinstance.py
  

• It creates a workingenv in the Zope instance for you.

• It installs the Plone egg by default. However, you could just as well install something else in your new Zope instance using the --requirements argument. ploneenv is not Plone specific.

These steps are quite similiar to what you do manually when you make your Zope instance a workingenv.

Give me some examples

This is how you use ploneenv to install Plone:

easy_install ploneenv

MKZO=~/lib/Zope-2.10/bin/mkzopeinstance.py
INSTANCE_HOME=$HOME/myplone30

ploneenv $INSTANCE_HOME -m $MKZO

At this point, you can install any extra packages. This would install simplegeneric:

source $INSTANCE_HOME/bin/activate
easy_install simplegeneric

Old-style Products that aren't wrapped in eggs are installed as usual:

cd $INSTANCE_HOME/Products
wget http://plone.org/products/ploneformgen/releases/1.0.3/ploneformgen_1-0-3.tgz
tar xzfv ploneformgen_1-0-3.tgz

You can also override Products that come with Plone. For example, you could set a symlink from your local CMFPlone checkout into the $INSTANCE_HOME/Products directory and hack away.

To use a local SVN checkout to develop an existing or new new-style Plone package, you would simply do:

cd ~/myproject
python setup.py develop

Note that except for the activation of the environment, this is exactly how you would install a package for development in Python (=setuptools). That is, this is not ploneenv nor workingenv specific.

Try it out!

Please try it out and give me feedback. As mentioned before, this is all you need to type:

easy_install ploneenv

MKZO=~/lib/Zope-2.10/bin/mkzopeinstance.py
INSTANCE_HOME=$HOME/myplone30

ploneenv $INSTANCE_HOME -m $MKZO

That's it! Just make sure that you set the MKZO and INSTANCE_HOME according to where your mkzopeinstance.py script is and where you want to create your instance respectively.

Now you can start Zope using $INSTANCE_HOME/bin/zopectl fg.

What's inside the Plone egg and why

The Plone egg goes back to some early experiments I did to package Plone. Plone is a meta-package that has a Products namespace and currently all old-style Products that Plone requires contained in it. On top of that, it defines a number of requirements, like elementtree and plone.openid.

By not mixing installation code with the package itself, the Plone egg makes sure that it can be installed in any context, for example in a ploneout.

If the CMF were to became available as an egg, Plone would remove it from its own contents and just define another requirement.

The tagged and released Plone egg (or bundle, if you like) should arguably not have svn externals that point to other Products' SVN trunks. Instead it should either use svn externals to SVN tags of Products where possible or include the Product itself if it's not maintained in subversion. This might seem a bit hacky, and Rocky says I'm cheating, but it effectively brings the Plone package more inline with other Python packages out there, with all the benefits that this brings. IMO, this should be the way to release Plone 3.0.

Discussion happens on the Plone development list.

Update: I've updated this entry to reflect the fact that ploneenv and Plone are now in the Cheeseshop, so the installation becomes a lot easier.

Update: I've retired ploneenv in favour of repoze (especially repoze.plone). repoze is what ploneenv wanted to be, and more.