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

[Chris McDonough]

On Thu, 2011-09-08 at 19:03 -0400, Chris McDonough wrote:
> 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__).

First cuts of this at:

http://svn.zope.org/zope.component/branches/chrism-zope.interface-componentregistry/

http://svn.zope.org/zope.interface/branches/chrism-componentregistry/

- C