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

[Wolfgang Schnerring]

Hello,

* Tres Seaver <tseaver at palladion.com> [2011-08-16 22:50]:
> The focus of the 2011 Pyramid GSoC project has been to port crucial
> Pyramid dependencies to Python3. At the end of this year's US PyCon,
> Lennart Regebro labelled[1] zope.component as "high-hanging fruit",
> due to the following factors::
> 
> - "magic"
> - Mostly tested via doctests
> - "Hairy" dependencies (e.g., zope.proxy, zope.security)
> - Many more optional / testing dependencies (ZODB3, zope.schema,
>   zope.configuration, etc.)
> 
> Based on IRC discussion at project kickoff[2], Joel Bohman, one of the
> two Pyramid GSoC students, has tackled this issue by factoring
> zope.component into two pieces:
> - Joel has moved the core registry bits into a new 'zope.registry'
>   package, now hosted in the Zope SVN repository:
> - Joel made zope.component depend on zope.registry in a branch:

I applaud both the direction of porting to Python3 and the drive
towards cleaning up / streamlining the ZTK packages. That's great!

However, I feel that this extraction of the registry bits is a little
too mechanical, and I'd like us to think a little bit about
alternative approaches before we commit this.

I envision the ZTK packages (like zope.component) to become more
standalone, less coupled to "the whole Zope world", but cohesive
pieces of functionality that can stand on its own.

In that light, I'd like to ask: what should be in zope.component, and
what shouldn't? My first stab at an answer goes something like this:

zope.component (aka the Zope Component Architecture) consists of
- the Registry concept
- filling out the Adapter concept of zope.interface
- the Site concept (setSiteManager, aka hooks.py)
- integration with zope.event (? a bit unsure here)
Something like that would make a coherent, usable package, I think.

At the moment, though, zope.component also contains (triggered via
different extra_requires):
- integration with zope.configuration (the <adapter/> and <utility/> directives)
- integration with zope.security
- integration with ZODB (persistent registries)

Those integration bits with "other parts of the Zope world" don't need
to be in there, I guess -- and as I understand it, precisely those are
the "hairy" dependencies that impede porting to py3.

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.

What do people think?

Wolfgang

-- 
Wolfgang Schnerring · ws at gocept.com · software development
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting