Re: RFC: Proposal for merging jbohman-zope.registry branch of zope.component

* Chris McDonough <[email protected]> [2011-09-06 20:06]:
> On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote:
> > * Chris McDonough <[email protected]> [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?

Yes, I like the idea of a "fresh start" (or at least "proper clean
up") quite a bit. And I'd definitely be up for writing (new)
documentation. You've set a great example in that regard with Pyramid
that is very much worth emulating for other packages.

> > > 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.

Isn't that a little too black and white?
I find value in the idea of removing the dependencies to ZODB, ZCML
and zope.security, while leaving zope.event/zope.testing in place.

> 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.

I agree, porting "the whole hairball" is way too much, and I
definitely wouldn't want to burden you/Pyramid with that.

Wolfgang

-- 
Wolfgang Schnerring · [email protected] · software development
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )