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

[Chris McDonough]

On Thu, 2011-09-08 at 13:39 +0200, Wolfgang Schnerring wrote:
> * Chris McDonough <chrism at plope.com> [2011-09-08 05:21]:
> > On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote:
> > > 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.
> 
> I guess that extracting just a little bit right now won't get in the
> way of "doing things properly" (since that most likely means
> extracting a little more and then documenting it), and I certainly
> don't want to stand in the way there.
> 
> However, that means that the package currently called "zope.registry"
> will quite likely become the "future" of zope.component. In that light
> I'd really like to try and come up with a better name -- Jim?

I mentioned previously that it's not that much of a stretch to put this
code into zope.interface because zope.interface.adapter already defines
registry-ish stuff that possesses most of the same concepts as a
component registry.  It has a class named "AdapterRegistry" already that
has a very similar API as a full-on component registry.  The full-on
component registry really just an API implemented in terms of multiple
z.i.adapter.AdapterRegistry instances.

With that in mind, and in the interest of moving forward, I'd suggest we
just ditch the zope.registry package and move its code into
zope.interface.  Then there's no renaming to do at all, we can still
innovate in the future without necessarily decommissioning a package.
As a bonus, we'll have one fewer dependency package.

The zope.registry registration machinery sends events when its API is
called.   It'd be a bit sucky to have z.event as a hard dependency of
zope.interface.   But it'd be dead easy to change it to only send
registration events if zope.event could be imported.  I doubt there's
anything listening for these events that doesn't also already depend on
zope.event.

zope.registry also currently provides a minor API in the way of an
"adapts" decorator.  This could (and should) be moved back into
zope.component; it's actually not used internally by zope.registry now
(although some decoy imports would make you think so if you look at
zope.registry.__init__).

- C