[Zope-dev] zcml entry points

[Jim Fulton]

On Oct 17, 2007, at 4:44 PM, Wichert Akkerman wrote:

> A common issue we are seeing is that we have eggs depending on each
> other, but they still need to load the zcml from those dependencies
> somehow. As a temporary solution to play with the concept I added
> something simple to the plone.recipe.zope2instance buildout recipe.
>
> It allows you to define entrypoints like this:
>
>       entry_points={
>           "zope.zcml" : [
>               "meta = plone.session",
>               "configure = plone.session",
>           ],
>       },
>
> this tells the system to load meta.zcml and configure.zcml from  
> plone.session.

Sure, where presumably you could list multiple files.

Or maybe:

   entry_points = """
   [zcml]
   meta = <include package="plone.session" />
   configure = <include package="plone.session" />
   """

   ...

   entry_points=entry_points

(This example uses the ConfigParser syntax for specifying entry  
points, which I prefer.)

This suggestion gives you the flexibility to specify ZCML to be  
included by package name, by file name, or both.
It lets you specify other ZCML as well.

>       entry_points={
>           "zope.zcml" : [
>               "meta = plone.session",
>               "configure = plone.session",
>           ],
>       },


> I am not quite sure what the best way to hook this into Zope itself  
> is.
> For Zope 2 we can do it in Five, since that is where all the zcml  
> loading
> logic currently is. Or we could move that into Zope2 itself somewhere.
> I'm not familiar enough with Zope3 to know what the best place  
> would be there.

I recommend creating new configuration directives that do this.

   <include meta_entry_points />
   <include entry_points />

These directives might also accept an projects attribute to name  
specific eggs, by project name, to load from.

This could be used in Zope 2 and in Zope 3 apps that want it. (Mine  
wouldn't. :)

Doing it this way keeps it simple to use while providing some added  
flexibility to do explicit configuration before or after this  
automatic configuration.

> One problem is ordering: the zope.component zcml needs to be loaded  
> first.

As Tres noted, a package that needs zope.component to be included  
should include it.  In general, I recommend that a package include  
all of the ZCML it expects to be included.

I understand that some folks would fine something like this to be  
very useful.  I can especially see the benefit for pluggable apps,  
like Plone and Zope 2..  I support this idea.  I would almost  
certainly not use it myself and can't justify my time to implement  
this. I think the implementation is pretty straightforward though and  
encourage folks who want this to implement it.  It can be implemented  
as a separate package, although I wouldn't object to eventually  
incorporating it into zope.configuration.

Jim

--
Jim Fulton
Zope Corporation