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

[Chris McDonough]

On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote:
> * Chris McDonough <chrism at plope.com> [2011-09-06 20:06]:
> > 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?
> 
> 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.

I'm behind the goal of cleaning up and documenting componenty things
better, and I think those are very worthy ideas.  But I think blocking
the proposed division while we hash out the details of what some second
generation zope.component might be is probably not in anyone's best
interest.  If there were some branch laying around with a proposed set
of changes, it might be more reasonable, but there's not, and it will
take months to create one (after discussion, planning, development,
rehashing, etc).  The creation of a second package today that just holds
the proposed bits doesn't prevent future innovation, AFAICT.

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

I don't share this particular goal, except for in a very general "yes it
would be nice to clean stuff up" sort of way.

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

That's appreciated, but blocking the currently proposed division (at
least without some alternative code) will have the same effect.

- C