On Fri, 2011-09-09 at 00:57 -0400, Chris McDonough wrote:
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-componentr...
http://svn.zope.org/zope.interface/branches/chrism-componentregistry/
I have merged these two branches to their respective trunks: z.i: https://mail.zope.org/pipermail/checkins/2011-September/057121.html z.c: https://mail.zope.org/pipermail/checkins/2011-September/057124.html If no one has issues with this, I will make releases of both within the next few days. - C