faassen at startifact.com
Tue Dec 23 12:38:11 EST 2008
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
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
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
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
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
More information about the Grok-dev