Hello, * Tres Seaver <tsea...@palladion.com> [2011-08-16 22:50]: > The focus of the 2011 Pyramid GSoC project has been to port crucial > Pyramid dependencies to Python3. At the end of this year's US PyCon, > Lennart Regebro labelled[1] zope.component as "high-hanging fruit", > due to the following factors:: > > - "magic" > - Mostly tested via doctests > - "Hairy" dependencies (e.g., zope.proxy, zope.security) > - Many more optional / testing dependencies (ZODB3, zope.schema, > zope.configuration, etc.) > > Based on IRC discussion at project kickoff[2], Joel Bohman, one of the > two Pyramid GSoC students, has tackled this issue by factoring > zope.component into two pieces: > - Joel has moved the core registry bits into a new 'zope.registry' > package, now hosted in the Zope SVN repository: > - Joel made zope.component depend on zope.registry in a branch:
I applaud both the direction of porting to Python3 and the drive towards cleaning up / streamlining the ZTK packages. That's great! However, I feel that this extraction of the registry bits is a little too mechanical, and I'd like us to think a little bit about alternative approaches before we commit this. I envision the ZTK packages (like zope.component) to become more standalone, less coupled to "the whole Zope world", but cohesive pieces of functionality that can stand on its own. In that light, I'd like to ask: what should be in zope.component, and what shouldn't? My first stab at an answer goes something like this: zope.component (aka the Zope Component Architecture) consists of - the Registry concept - filling out the Adapter concept of zope.interface - the Site concept (setSiteManager, aka hooks.py) - integration with zope.event (? a bit unsure here) Something like that would make a coherent, usable package, I think. At the moment, though, zope.component also contains (triggered via different extra_requires): - integration with zope.configuration (the <adapter/> and <utility/> directives) - integration with zope.security - integration with ZODB (persistent registries) Those integration bits with "other parts of the Zope world" don't need to be in there, I guess -- and as I understand it, precisely those are the "hairy" dependencies that impede porting to py3. 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. What do people think? 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 1229889 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 )
