On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote:
* Chris McDonough <chrism@plope.com> [2011-09-01 04:27]:
It wouldn't be the end of the world to have the global registry and the global API live in zope.registry, but it doesn't help Pyramid for it to be in there, and it probably wouldn't help anyone else either. The global API (which includes getSiteManager) is really just a convenience feature, and splitting that global API across more than one package doesn't seem to make sense to me.
I guess this is the central issue where we have different opinions. I don't consider those "just convenience", but rather concept-bearing of their on right.
"Convenience" and "concept bearing" aren't mutually exclusive. Whom would be served if we moved the global API to zope.registry? Are you thinking that zope.registry would be some sort of "fresh start" for zope.component? If so, is anyone willing to promote it, write new docs, etc?
It might make sense for the entire global API to be in zope.registry, but if you take "global API" to mean what it does now that implies dependencies on at least:
- zope.event (zope.component.event.dispatch) - zope.testing (for addCleanUp of the global registry in z.c.globalregistry and other places)
Yep, those two would be necessary.
This is a bit icky for me. I'd rather have something with fewer dependencies, or at least dependencies I actually use.
It also implies conditional dependencies on zope.security (in z.c.hooks.setSite, and other places), which are even now pretty nasty.
But I don't see where that would come from. As far as I understand it, hooks.setSite wouldn't be in zope.registry.
If we were to move all this stuff into zope.registry, I think we'd do just as well to leave zope.component as-is, but port all of its dependencies to Python 3. Although that's a noble goal, I personally won't be doing that any time soon; I'd instead just take the code we actually from zope.component and put it into Pyramid itself. - C