[Grok-dev] [PSPS08] Salt - kills slugs!

[Martin Aspeli]

Hi all,

This is another Plone Strategic Planning Summit follow-up. This wasn't 
directly a focus area since iet's so small, but I feel it's important 
regardless.

I'm also CC'ing the Grok list, since I know they've worked on something 
similar (but not quite the same - see below) and may have some 
opinions/suggestions.

I think Wichert and Hanno have already done some work on this. With 
luck, we can get this for Plone 3.2, or as an add-on earlier.

The proposal text is below.

Cheers,
Martin

===================
Salt - Kills Slugs!
===================

ZCML slugs are a pain and frequent source of confusion. For pluggable 
systems such as Plone, we generally want to load the ZCML configuration 
for every package that broadcasts that it is a Plone package. Buildout's 
concept of a working set of eggs makes it relatively easy to predict 
what will be installed.

User story - installing an egg-distributed package
--------------------------------------------------

The user edits buildout.cfg and adds a line to the 'eggs' option for a 
package he wants to install. He runs ./bin/buildout and the package is 
installed. It is found at Zope startup and all ZCML is loaded properly.

User story - installing an development egg
------------------------------------------

The user adds a new develop egg to buildout.cfg and runs ./bin/buildout. 
Its ZCML is loaded on startup without having to explicitly register slugs.

Implementation
--------------

A new package, 'plone.salt', provides the facility for packages to use 
an entry point that points at a ZCML file. The entry point comes in 
variants for configure.zcml, meta.zcml and overrides.zcml, and includes 
an identifier (e.g. 'plone') and optionally a version specification that 
make it clear which platform the package is aimed at. For example, the 
entry point may be:

  [plone.salt]
  configure:plone[>=3.0,<4dev] = my.package:configure.zcml
  meta:plone = my.package:meta.zcml

Plone itself includes a single line of ZCML for each type of 
configuration file (configure.zcml, meta.zcml and overrides.zcml) that 
will include the relevant files in all registered packages. Inside 
Products.CMFPlone, this may look like:

  <plone:includePackages
     type="configure"
     target="plone"
     version="3.0.4"
     />

Behind the scenes, this will find all ZCML files registered for target 
'plone' of type 'configure' which apply to version 3.0.4.

Note that this system is opt-in both for the packages and for the 
pluggable system (Plone in this case). ZCML will not automatically be 
loaded by other Zope 3 systems where the same egg happens to be on the 
module path, and Plone will not scan the module path looking for any and 
all packages that it could install. It is possible for a package to 
broadcast its configuration for multiple systems that subscribe to 
different identifiers than "plone".

The Grok project have created a system that can load all ZCML for 
packages listed as dependencies (install_requires) of a given package in 
its setup.py. This approach is complementary. For example, an add-on 
product may use this mechanism to ensure that its dependencies are 
automatically loaded, but would still use plone.salt to ensure that it 
was easy to install for Plone. It may be desirable to put both of these 
types of functionality in the same package, however.

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book