Hey, Tres Seaver wrote: [snip]
repoze.bfg takes yet another approach. I'm sure there are new ZCML directives it introduces, but it also forked the current ZCML directives that are in zope.component for basic component registration, to reduce its dependencies. Perhaps that fork can be undone if we improve the way we break things down (to anticipate what you're saying below).
The fork is not merely to reduce dependencies: BFG also wants to eliminate the requirement that there be "one global component registry to rule them all," which is pretty deeply embedded in zope.component. Breaking that assumption allows multiple BFG apps to run in the same process, with incompatible components registered, without any chance that they will step on each other's toes.
Cool, I hadn't realized that. I think it would be useful to fold that support into the Zope framework itself too. [snip]
"Reusable configuration" is a bit of an oxymoron: if everybody *must* use the configuration, then it isn't configuration at all, but software.
I think, however, that this discussion is about where to put the "meta" bits (the parts which actually implement ZCML directives), rather than rehashing the library vs. application problem (where to put the configuration).
Yes. My interpretation of what Hanno said was that he was talking about reusing the implementation of configuration. I.e. repoze.zcml might define an action that zope.componentconf might use in the implementation of its own actions. Anyway, no matter what Hanno said, I think that is an interesting area to explore. Grok and Five both want to reuse as much of the underlying action implementation in the Zope framework as possible. [snip]
I would argue that putting any ZCML-related implementation in a separate package from the zope.component core would be a win, at least from the perspective of clarity and dependencies.
Agreed. It might be that the core implementations of actions a-la repoze.zcml could be moved into zope.component. repoze.zcml could then become a smaller package that simply registers the directives themselves for these actions. We could then have something that builds on this (and zope.security) to implement the directives that zope.component now implements. Regards, Martijn