Hi Martijn,

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 
> zope.security.


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 - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to