* Jim Fulton <j...@zope.com> [2011-08-26 07:35]: > On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring <w...@gocept.com> wrote: > > * Jim Fulton <j...@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 · w...@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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )