[Grok-dev] Dependencies

[Chris McDonough]

Martijn Faassen wrote:
> Chris McDonough wrote:
>> Martijn Faassen wrote:
>>
>>> 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. :)
>> You could just use this:
> 
> Thanks for the pointer. Thinking about it, I don't think it's that 
> simple, though.
> 
> Your documentation seems misleading. zope.configuration does not provide 
> implementations of these directives at all. The implementations are in 
> fact in zope.component.

You're right.  That's a typo.  Twice. ;-)

> You get a host of dependencies when you need to use zope.component *and* 
> need the ZCML directives to work (the zcml extras_require in 
> zope.component). grokcore.component only needs the former, not the latter.

You get much the same effect when you depend on zope.security instead of using
the [zcml] extra, FWIW.

> I also just realized that grokcore.component already reuses the action 
> implementations in zope.component. grokcore.component simply doesn't 
> require the zcml extra so won't pull in all the spurious dependencies.

The zope.security package seems to be a mini-hairball of dependencies.
zope.security depends on zope.component, which depends on zope.security if the
[zcml] extra is specified.  If I could make a cross-eyed emo icon here, I would.
;-)  This might be the place to start slashing if anyone cared about this
particular hairball.  But you probably don't, as Grok depends on it all anyway,
as you said.

> So in effect we'd be increasing the amount of packages that 
> grokcore.component (and Grok) relies on for no gain that I can see - we 
> already have in grokcore.component exactly the functionality repoze.bfg 
> provides, though not in ZCML directive form.

Yep.  FWIW, you may want to think hard about why the SubscriberGrokker needs to
call zope.component.interface.provideInterface if you want to support more than
one grokcore-using application per process.  Maybe it's to support zope.event?
I'd love to know what used the registrations made by provideInterface.

> We also can't reduce the dependencies of existing Zope 3 packages by 
> using repoze.zcml. In order to reduce dependencies it implements a 
> subset of the functionality in the original directives, and in order to 
> use Zope 3 packages we need that full functionality or we'd break 
> compatibility.

Yep.

> 
> I think right now the right area to focus on for Grok is in more 
> low-hanging fruit, such as reducing the amount of zope.app.* packages we 
> pull in.
> 
> Repoze's strategy to reduce dependencies seems to be one of 
> reimplementing a lot of Zope 3 code so it has less dependencies, but the 
> Grok project can't use that strategy so easily as we rely on that Zope 3 
> code.
> 
> Grok is tied to Zope 3. If Grok wants to have an installation without 
> pulling in as much as it does now, we need to improve Zope 3. The 
> alternative is to port Grok to an entirely different foundation. I don't 
> see that as a viable option for Grok right now. We'd be implementing a 
> new, incompatible web framework, and that's what repoze.bfg is doing 
> already.

It is just that, yup.

- C