[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

Jean-Paul Ladage j.ladage at zestsoftware.nl
Sun Jan 28 17:10:19 EST 2007

>   - ploneout (http://svn.plone.org/svn/plone/ploneout/trunk) is really 
> an environment that Plone 3 core developers could (should?) use as a 
> consistent way of setting up a Zope 2.10 instance with Plone 3 and all 
> dependencies. It uses svn:externals quite extensively to pull in Plone's 
> source code into src/ (the eggs) and products/ (the products) with the 
> intention that this is the code being developed. Ploneout's README.txt 
> has more information about this scenario.

To through in an extra angle in this discussion, I would like to contribute the following thoughts.

Unless Utopia really exists I think developers all have their own thoughts about setting up their development environment. In my opinion buildout's target should be deployment of complex production systems.

I had to read the buildout documentation twice to even get a grip of it and yesterday I wondered around in a forest of recipes in ploneout. Although I see the value of buildout, copying over the entire buildout to setup a second sandbox, seems like a waste of disk space to me.

We work on quite a number of different projects at once and want to be able to reproduce a working instance (running the production Data.fs preferably). To service our environment we (mainly the van Rees brothers) wrote instancemanager.

We expect a minimal set of requirements:
 - Python installed
 - Zope libraries installed next to each other, e.g.
   /usr/local/zope/2.10.2, each version in a separate folder.

Using instancemanager you can:

* Create / Start / Stop / Restart instances

* Backup / Restore / Pack instance databases

* Install Products

* Run tests

* Generate Apache VirtualHost configs

* Easy upgrade Zope versions

During the Snowsprint we'll finish Windows compatibility and creation of Z3 instances.

Minimal configuration in ~/.instancemanager/userdefaults.py to show instancemanager which zope's are available.

  zope_location_template = '/usr/local/zope/%(zope_verion)'

Each instance is then configured using a project.py.


Inside this project file we can define all needed instance configuration options:

* Initial user and password

* Portnumbers

* Zope / Python version used

* Whether to use zeo, and how many zeo clients

* Sources to install in the Products or lib/python folder

   - symlink_sources : Allow svn checkouts of products to be linked.

   - symlinkbundle_sources : Allow for svn checkouts of bundles (3.0)

   - archive_sources: Allow for official release tar files to be 

   - archivebundle_sources: Allow for official release tar bundles to be 

  Sources are defined as a list of dicts:

      archive_sources = [

  Here I defined two developers tools that need to be downloaded and extracted to
  the Products folder of my instance. 
      symlinkbundle_sources = [
  Here I define the 3.0 bundle of Zope Products that will be symlinked and for
  the second we added the key 'pylib' a value of True to indicate this set of sources
  need to be linked in the lib/python folder.

  Sources are downloaded to a configurable location, instancemanager has set the
  following defaults:

     archive_basedir_template = /home/myuser/downloads
     archivebundle_basedir_template = /home/myuser/downloads
     symlink_basedir_template = /home/myuser/svn
     symlinkbundle_basedir_template = /home/myuser/svn

  Downloading happens only once, to limit bandwidth.

Again most developers are pretty demanding about setting up a development environment.
Here at Zest most of us are comfortable with instancemanager.

There's an egg available in the cheeseshop, but for the latest features you can also checkout


Kind regards,


More information about the Zope-Dev mailing list