Without comparison otherwise, you may find my thoughts here useful:
> 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.
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.
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
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.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -