* Jim Fulton <jim@zope.com> [2011-08-26 07:35]:
On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring <ws@gocept.com> wrote:
* Jim Fulton <jim@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@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