[Grok-dev] Dependencies

[Martijn Faassen]

Hey,

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 
> dependencies:
> 
>   zope.location-3.4.0-py2.4.egg
>   zope.publisher-3.5.4-py2.4.egg
>   zope.security-3.5.2-py2.4-macosx-10.5-i386.egg
>   zope.traversing-3.5.0a4-py2.4.egg
>   zope.i18n-3.6.0-py2.4.egg
>   pytz-2008i-py2.4.egg

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.

Regards,

Martijn