plonewars.com

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.
  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 would use ploneenv to install Plone once it is
registered with the Cheese shop (i.e. you can’t do that yet):

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

At this point, you could install any extra packages like this:

source $INSTANCE_HOME/bin/activate
easy_install Listen

This would install the hypothetical Listen package including all its
dependencies in your Zope instance.

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 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.
(In the same way that Zope Buildout is not Zope specific.)

Try it out!

Since ploneenv is not registered with the Cheese shop yet, and the
Plone egg isn’t completed yet, the installation is a bit more
involved. We have to easy_install ploneenv directly from SVN and
also provide a link to the Plone egg, which for now resides only in
SVN as well.

Follow these steps to try out ploneenv now and please give feedback.
I have only tested this in Linux for now. Make sure you set the value
of MKZO (the path to your Zope’s mkzopeinstance.py) according
to your installation:

MKZO=~/lib/Zope-2.10/bin/mkzopeinstance.py
INSTANCE_HOME=$HOME/myplone30
easy_install 
    http://danielnouri.org/svn/scratch/ploneenv/trunk#egg=ploneenv-dev
echo 'http://danielnouri.org/svn/scratch/Plone/trunk#egg=Plone-dev' > 
    /tmp/myrequirements.txt
ploneenv $INSTANCE_HOME 
         --requirements=/tmp/myrequirements.txt 
         --mkzo=$MKZO

That’s it! Now you can start Zope using $INSTANCE_HOME/bin/zopectl
fg.

Note that ploneenv and the Plone egg are a work in progress right now,
and that most of these steps will become obsolete, so that only this
will be left to do to install a Zope instance with Plone 3.0 in it:

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

And because the Plone egg defines all of its dependencies, the list of
eggs in buildout.cfg can be reduced to this:

eggs =
    Plone

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 PIL 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.