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

[Jim Fulton]

On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring <ws at gocept.com> wrote:
> * 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].

But it still contains code to go with those dependencies. To clean
this up, you'd have to remove that code, which would cause breakage.

> 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?

It could if you didn't care about backwards compatibility.

>
> 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...

It would still have that name.

>
>> 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.

That's everyone's goal. The current contents of zope.component
aren't all that cohesive.  I haven't looked at the registry branch
but I assume and hope that the registry package includes the core
functionality.

>
> The current zope.component, because it came out of the Zope3 monolith,

That's not right. When Zope3 was managed as a single whole, zope.component
was far more cohesive and less tangled than it is now. It gained a
bunch of cruft
in the rush to kill zope.app.component when code was moved from
zope.app.component was mistakenly moved to zope.component.

The reason we created zope.app in the first place was to
prevent application-framework-specific policies from polluting
the more general packages.

> contains integration bits to various other Zope packages:
> - zope.event

I think treating integration with zope.event as core would be
reasonable.

> - 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.

Me too. I wish the destruction of zope.app.component had happened
differently.  I'd like to have meaningful names, but I'd rather not
incur more backwards incompatibility to get them.

It's certainly valid to argue for the backward incompatibility. It's a tradeoff.

> 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).

IMO, what's core is a way to plug in component registries, not a
particular strategy for component registries.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton