faassen at startifact.com
Tue Dec 23 10:44:57 EST 2008
Martin Aspeli wrote:
> A long and somewhat side-tracked discussion on the Repoze lists can be
> summarised thus: The BFG people (Chris mainly) ended up implementing a
> repoze.zcml package that re-implements <adapter />, <utility /> and
> maybe some other directives (<subscriber />, I guess?) sans support for
> trusted components. This meant BFG could shed the following unused
Those aren't dependencies of grokcore.component either, which implements
adapter, global utilities and event subscription.
I think this is the case as grokcore.component is effectively doing what
repoze.zcml is doing: reimplementing the behavior of these directives,
in our case not for ZCML directives but in Grok terms.
Grok itself cannot shed these packages just like that though. The full
Grok (or probably even something like grokcore.view) will still need
these packages as we depend on packages that need them. I'm not sure
whether it'll be easy/sensible to get rid of many of those listed there.
I'd like to see some consolidation between some of them nonetheless,(
nonetheless (publisher and traversing in particular have a lot of stuff
spread out over packages). For Grok, I'm especially interested in
getting rid of our dependencies on zope.app.* packages.
> Since there's been discussion about Grok's desire to reduce
> dependencies, perhaps this is something that could be adopted lower in
> the stack (e.g. making those dependencies optional or at least opt-out
> in Zope 3), thus benefiting everyone?
That would be good. I think it should be possible to factor out common
registration functionality (basically the ZCML actions) that
grokcore.component can then also use, instead of implementing its own.
Note that this would actually *add* a dependency to grokcore.component,
but we'd gain the ability to use the ZCML directives too without
depending on the above packages, so we're willing to make that sacrifice
for the Good of the People. :)
> Chris has promised to help out if anyone can constructively help push
> this into Zope or find a better solution than BFG having to invent its
> own versions of these directives. I'm just a messenger, but Plone is
> also interested in a smaller dependency graph and so there may be ways
> to work together there as well.
> Anyone interested in pushing this forward?
I am; in late january a bunch of us are getting together in a small
sprint to push this kind of stuff forward as well, with a focus on Grok.
It'll probably be a combination of reorganization of underlying Zope
packages and reimplementation of some behavior.
More information about the Grok-dev