On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote: > * Chris McDonough <chr...@plope.com> [2011-09-06 20:06]: > > On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote: > > > * Chris McDonough <chr...@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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
