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

[Wolfgang Schnerring]

* Jim Fulton <jim at zope.com> [2011-08-25 15:24]:
> On Thu, Aug 25, 2011 at 2:50 AM, Wolfgang Schnerring <ws at gocept.com> wrote:
>> 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 would agree if we were starting over.  But the damage is done
> and stripping zope.component to its core would be backwards
> incompatible now.

Why? zope.component already uses extras_require to signify the various
integration parts: [persistentregistry,security,zcml].

As far as I understand the thrust of the zope.registry effort, it is to
untangle those to make porting easier (which requires those bits not to
be in the same package, I guess, because of import problems or
whatnot?).

I think the same effect could also be achieved by splitting these
integration bits into separate packages, and leaving the
extras_require's in zope.component to depend on said new packages,
couldn't it?

But that's only technicalities in search of meaningfully preserving the
name zope.component for the core package (because that's the name it
always had), and...

> This is, OTOH, an opportunity to maybe come up with a more appealing
> name.  While I like the term "component", my sense is that it probably
> feels too heavy to a lot of Python programmers.  "Registry" is at least
> as bad and doesn't reflect the real use case.

... I agree that an alternative is to give the core a new name.

However, what's important to me is that we try to make packages
cohesive, and that we try to make integration between packages
understandable.

The current zope.component, because it came out of the Zope3 monolith,
contains integration bits to various other Zope packages:
- zope.event
- zope.security
- zope.configuration
- ZODB

In that light, it makes a lot of sense to me to have two (or more?)
packages, "core" and "integration", but I'd *very* much like them to be
named in a way that one can tell this fact from their names.

What remains is the issue that zope.component *also* contains code for
the thread-local site concept -- which doesn't feel like an integration
with another package, but might not be considered core functionality,
either (I'm not sure yet but I lean towards considering it core).

Wolfgang