Hey, Carsten Senger wrote: [snip] > zcml contains many useful informations and I often use it as > documentation how things fit together. It would be a loss to detach all > zcml from the implementations into one/few big zcml packages. > Moving them into one dedicated zcml for every package leaves them > logically related to the implementation. > It's also easier to maintain: > > - The zcml for an implementation has the same release cycle as the > implementation. > - Every relevant change in an implementation would need changes by a > number of "zcml package maintainers" (Grok, Zope2, Zope3ZMI) that > don't know the package nearly as good as the package maintainer. > > I would prefer to find them inside the implementation packages where > possible. Where it's intended to reduce dependencies a dedicated zcml > package like zope.i18n_zcml is at least more clear.
You make good points in favor of keeping this information close together. I'll note that with grok-style packages it's actually not *possible* to remove the information out completely, as it's in the Python code. You can choose not to configure this code at all, but that's it. I think whether ZCML is useful depends, in part, on much on how much ZCML a package defines today. If a package defines a little bit of ZCML only, I think it's less of a risk to pull it out. If a package defines a *lot* of ZCML, we will have to wonder about the purpose of the package (is this really a library-like package or more like an application defining a UI or something?), and we'll have to think about another strategy. I want to move this discussion to concrete examples next and see what a treatment of moving out ZCML would entail. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )