[Zope-dev] ZCML implementations: where should they go

Martin Aspeli optilude+lists at gmail.com
Sat Feb 7 20:38:56 EST 2009


Hi Martijn,

Without comparison otherwise, you may find my thoughts here useful: 
http://www.martinaspeli.net/articles/granting-plone-an-api

> a) continue with the current extra dependencies situation like in 
> zope.component, and in fact clean up other packages that define ZCML to 
> declare ZCML extra dependencies.

-0.5

I think this will require more discipline than usual, and it'll a pain 
to test how a package behaves both with and without extras.

> b) pull out all ZCML implementations from where they are now and put 
> them in special ZCML implementation packages. We could for instance have 
> zcml.component, or zope.component_zcml, or zope.configuration.component. 
> We had a bit of a side-tracked discussion about naming and namespace 
> packages here.

+0.5

I would suggest we have a namespace package and a naming convention to 
allow this to grow over time. For example, we could have a zope.zcml.* 
naming convention, so you'd have zope.zcml.component, zope.zcml.content 
and so on. Having a single package could become painful when people 
start refactoring and branching, as you could easily get into situations 
where it becomes hard to upgrade or manage releases.

> c) pull out only those ZCML implementations that cause extra 
> dependencies beyond zope.configuration. So, we extract the bits of 
> zope.component into a new package, but we don't extract bits from 
> zope.security.

-0.5

This policy sounds confusing to me, which means that people will 
probably screw it up. :)

> For that reason, a) is not really an option for me. That leaves b) and 
> c). I think for now we should go with c), as it's the smallest step 
> forward that will help clean up things. That is, we either find and 
> appropriate package that makes sense for the ZCML implementations in 
> zope.component, or we create a new package. Of course if we create a new 
> package we still have a naming discussion ahead and I risk sparking 
> another naming discussion (as it's easy to have an opinion about names).
> 
> So, what do people think about option c)?

I see no problem with starting with zope.component, but I'd consider 
both naming conventions and package structure conventions in a wider 
context before making the leap with zope.component, to reduce the chance 
of inconsistencies in the future.

Martin

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



More information about the Zope-Dev mailing list