#247: Automate ZCML Loading for Plone Plug-ins

Contents
  1. Definitions
  2. Motivation
  3. Assumptions
  4. Proposal
  5. Implementation
  6. Deliverables
  7. Risks
  8. Participants
by Andreas Zeidler last modified Jan 21, 2010 07:29 AM

Enable automatic plugins for Plone with z3c.autoinclude

Proposed by
Ethan Jucovy
Seconded by
Martin Aspeli
Proposal type
Architecture
Assigned to release
State
completed

Definitions

autoinclude: z3c.autoinclude, a package (http://pypi.python.org/pypi/z3c.autoinclude) for automatically including ZCML files from dependencies and plugins.

Plugin package: a package providing some extended functionality to Plone activated by execution of ZCML configuration.

Motivation

Installation of packages that extend Plone's functionality is currently somewhat burdensome. Most extension packages will provide ZCML that must be loaded in order for the package to function properly. The standard way of installing these plugin packages is to use ZCML slugs in the package-includes directory, typically marked in a buildout.cfg file for replicability. However, this is a burdensome process: editing the installed plugins involves editing the buildout.cfg file and re-running buildout, or adding and removing symlinks and files on the filesystem; there is no straightforward way to share different permutations of plugins without making nearly identical copies of buildout.cfg files; and the process involves unnecessary repetition of package names as requirements and plugins, a subtlety that integrators, particularly beginners, might easily overlook. A more automated and implicit system of loading plugins would eliminate this error-prone process.

Assumptions

Packages signal to autoinclude that they are plugin candidates by setting a setuptools entry_point, so plugin packages must be packaged as setuptools eggs.

Proposal

Explicitly invoke autoinclusion of plugins for Plone. This would look like:

<includePlugins package="plone.app" />

at the end of the CMFPlone/configure.zcml file, within the <configure> directive.

Plugin packages would then signal that they should be included by adding:

setup(...
entry_points="""
...
[z3c.autoinclude.plugin]
target = plone
...)
"""

to their setup.py file.

Implementation

See Proposal above.

Deliverables

See Proposal above.

Risks

autoinclude computes the packages to include at Zope startup, when each <include*> directive is executed, so it slows down the startup time. The execution time of the algorithm used is dependent on the number of entries in sys.path, so this slowdown may become unacceptable in environments with many eggs installed. This can be mitigated by future improvements in z3c.autoinclude like optimizations to the algorithm or a "freeze" script to compute autoinclusion packages once and output to a ZCML file.

Participants

Ethan Jucovy

Framework team vote (for Plone 3.3)

Posted by Andreas Zeidler at Oct 27, 2008 11:35 PM
+1

3.3 Framework team vote

Posted by Martijn Pieters at Oct 27, 2008 11:43 PM
+1

Framework team vote

Posted by Danny Bloemendaal at Oct 28, 2008 08:14 AM
I have the gut feeling that it seems like a good idea but I cannot judge that myself so I refrain from voting on this one.

Framework Team vote

Posted by Tom Lazar at Oct 28, 2008 10:54 AM
+1 although i would be interested in the slowdown in start up time...

some more considerations

Posted by David Glick at Jan 10, 2009 07:45 PM
I know this PLIP is already accepted, but I would like to see a consideration of what documentation will need to be adjusted in order to get add-on product developers actually adding the entry point, as well as a consideration of any impact on the test environment (this will result in more products getting loaded which will take longer and may be unexpected by some test authors...though I'm not sure the latter actually matters)

some more considerations

Posted by Andreas Zeidler at Jan 12, 2009 09:10 AM
big +1! and yes, having effects on the test environment does matter as the extra (autoloaded) zcml might change things significantly, potentially causing tests to behave differently. i don't know what the status is, but imho autoloading should better be left disabled for tests (if possible)...

some more considerations

Posted by Ethan Jucovy at Feb 10, 2009 12:57 AM
Re: test environment considerations, http://lists.plone.org/[…]/002701.html -- z3c.autoinclude can now be disabled (by a test runner, etc) by setting environment variables

Plone 3.3 framework team review #1

Posted by Martijn Pieters at Jan 25, 2009 03:04 PM
I've updated the buildout to not use buildout.eggtractor; you already had
disabled it's zcml autoloading but didn't add Products.CMFPlone to the zcml
line. Not using buildout.eggtractor at all is a better idea here, however.

I've also added a foo.cfg buildout configuration to test the (very nice!)
demonstration package. Just run bin/buildout -c foo.cfg to have the foo
package included.

After these changes, the z3c.autoinclude package appears to work as
advertised. However, when running the z3c.autoinclude tests I see test
failures, which worries me. I understand that the package is being used by
Grok as well, and this PLIP merely covers the inclusion of the package into
Plone, but I'd like to see some comments about what these test failures are
about.

Until I see comments that alleviate my concerns about the test failures, I'm giving this PLIP a +0.

Plone 3.3 framework team review #1 update

Posted by Martijn Pieters at Jan 30, 2009 09:06 PM
The test failures have been fixed, and my verdict is now a +1.

Framework team vote (for merging into Plone 3.3)

Posted by Andreas Zeidler at Feb 05, 2009 04:37 PM
+0 for now (please see http://lists.plone.org/[…]/002688.html for details)

Framework team vote (for merging into Plone 3.3)

Posted by Andreas Zeidler at Feb 12, 2009 12:46 PM
i'm revising my vote to +1 after Ethan's recent updates (see http://lists.plone.org/[…]/002713.html)