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

[Chris McDonough]

On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote:
> * Chris McDonough <chrism at plope.com> [2011-08-26 13:27]:
> > > So I'd like to propose to do the split the other way around: Not
> > > extract the core into something else and leave only a hollowed-out
> > > shell of integration and miscellany stuff behind, but rather tighten
> > > zope.component to its core and move the optional integration bits out
> > > of it, into separate packages.
> > 
> > I'm -1 on redefining the meaning of zope.component.
> 
> I'm afraid I don't understand what you're saying. Could you expand on
> this? What meaning is redefined to what by which proposed action(s)?

My interpretation of your suggestion is that maybe that "zope.component"
end up as what "zope.registry" is now.  But I don't think preserving the
name "zope.component" for this small core and spinning off everything
else in the package into separate bits is very attractive, because
"zope.component" is just a name and we can do it with a lot less churn
and potential for bw incompat if we just rename the core bits rather
than changing the meaning of "zope.component" to be "just the core
bits".

If there's some solution that doesn't break bw compat but gets what
you're after, I couldn't possibly be opposed to it.  But I don't see how
it can happen without some backwards incompatibility, even if that
backwards incompatibility is the requirement that a user install
setuptools extras to get what used to come along with the core.

> > Otoh, if the name "zope.registry" (or the introduction of a new
> > package) is a problem, I'd suggest we move the stuff that is
> > currently in "zope.registry" to zope.interface. zope.interface
> > already contains a bunch of registry-related code; it'd make
> > complete sense to me.
> 
> That's an interesting suggestion, since zope.interface contains the
> bigger half of all the adapter mechanics already. (zope.interface
> would gain the concept "utility", an adapter "from" nothing, but I
> wouldn't mind that, I guess.)
> 
> However, my main driving point here is coherent package boundaries,
> and as said elsewhere in this thread, I think that the core of
> zope.component comprises more than just the Registry class, namely the
> (hookable) getSiteManager protocol and probably zope.event integration
> -- and I'm not sure that all this belongs into zope.interface.

As far as I'm concerned, the ZCA global API and zope.event machinery are
not "guts"; they are convenience APIs on top of the guts.  Each promotes
the idea that there is a single registry per process, which is not
always true (it's not in Pyramid, anyway).  I'd be a -1 on seeing these
sorts of convenience APIs come along for the ride into the "guts"
package, whatever that ends up being.

- C