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

[Wolfgang Schnerring]

* Jim Fulton <jim at zope.com> [2011-08-26 07:35]:
> 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]:
> > > 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.

I have the feeling I'm missing or overlooking something. Could you
help me find it? These are the two scenarios, as I understand them:

a) zope.component declares an extras_require "foo", making it depend
on zope.foo, and also has a module zope.component.foo with integration
code in it.

b) zope.component declares an extras_require "foo", making it depend
on zope.foo *and* a new package zope.component_foo (which contains the
extracted integration code). Also, zope.component has BBB imports in
zope.component.foo that point to zope.component_foo.

My understanding is that from a client's perspective these two are
equivalent: if you want the foo functionality for zope.component, you
have to depend on zope.component[foo], and you import stuff from
zope.component.foo.
 
> > 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.

Ah, I wasn't properly aware of that part of its history. Thanks for
clarifying!

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

That makes sense. Event handlers certainly feel like a useful (and
widely-used) feature to me.
 
> > - 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.

I think I don't want to argue for incompatibility, but rather I am
glad that we are exploring what degrees of freedom for improvement
remain available to us while still preserving compatibility.

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

Do I understand you correctly that the fact that getSiteManager is
"hookable" should be core, but the thread-local mechanism of setSite()
should not? That seems like a very useful delimination.

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 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting