[Grok-dev] Dependencies

[Martijn Faassen]

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 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.

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.

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.

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.

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.

Regards,

Martijn