[Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

Chris McDonough chrism at plope.com
Tue Sep 6 19:06:07 EST 2011


On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote:
> * Chris McDonough <chrism at 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




More information about the Zope-Dev mailing list