On Feb 7, 2009, at 11:07 AM, Martijn Faassen wrote:
Hi there,
We've recently had some discussions on where to place the implementation of various ZCML directives. This post is to try to summarize the issue and analyze the options we have.
Right now ZCML directives are implemented in packages that contain other implementation. For example, zope.component implements various ZCML directives, and zope.security implements some more.
In the case of zope.component, a special [zcml] extras dependency section is declared. If the ZCML dependencies are asked for, using zope.component will suddenly pull in a much larger list of dependencies than the original zope.component dependency list. The ZCML directives are component-related, but do offer extra options that need bits from the wider Zope 3 framework, such as the security infrastructure.
In the case of zope.security, this isn't the case. As far as I can see, it doesn't declare any dependency beyond zope.configuration to allow it to implement its ZCML directives.
The dependency situation for the ZCML implementations in zope.component doesn't appear ideal. It was therefore proposed to move the ZCML implementations to another package. This could be a new package, or it could be created.
Following up on that, it was considered we should move *all* directives from the packages that implement them now into special packages. This would allow some packages to lose the dependency on zope.configuration, which is a relatively minor gain.
We have several ways to go:
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 did this in zope.component out of desperation. (I was preparing to teach a PyCon tutorial on using zope.component outside of Zope.) I'm not at all happy with it, however, I'd be in favor of continuing it for existing packages with zcml implementations so as not to introduce backward incompatibilities. I'd rather not do it for new packages. IMO, introducing an extra is like introducing a new package and in a rather complicated way.
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 think this is the right way to go for new software.
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.
Too complicated imo. :)
I personally don't like extras. I think the ideal situation would be if packages had *no* extras at all (even test extras), as it complicates reasoning about the dependency structure.
+1 ...
For that reason, a) is not really an option for me.
As I said above, I'm for a) because I think it is less disruptive, even though I share your distaste for extras. Jim -- Jim Fulton Zope Corporation