On Thu, 2011-08-25 at 08:50 +0200, Wolfgang Schnerring wrote:
However, I feel that this extraction of the registry bits is a little too mechanical, and I'd like us to think a little bit about alternative approaches before we commit this.
I envision the ZTK packages (like zope.component) to become more standalone, less coupled to "the whole Zope world", but cohesive pieces of functionality that can stand on its own.
In that light, I'd like to ask: what should be in zope.component, and what shouldn't? My first stab at an answer goes something like this:
zope.component (aka the Zope Component Architecture) consists of - the Registry concept - filling out the Adapter concept of zope.interface - the Site concept (setSiteManager, aka hooks.py) - integration with zope.event (? a bit unsure here) Something like that would make a coherent, usable package, I think.
At the moment, though, zope.component also contains (triggered via different extra_requires): - integration with zope.configuration (the <adapter/> and <utility/> directives) - integration with zope.security - integration with ZODB (persistent registries)
Those integration bits with "other parts of the Zope world" don't need to be in there, I guess -- and as I understand it, precisely those are the "hairy" dependencies that impede porting to py3.
So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages.
What do people think?
I'm -1 on redefining the meaning of zope.component. Otoh, if the name "zope.registry" (or the introduction of a new package) is a problem, I'd suggest we move the stuff that is currently in "zope.registry" to zope.interface. zope.interface already contains a bunch of registry-related code; it'd make complete sense to me. - C