[Grok-dev] Re: grok in the egg universe

[Philipp von Weitershausen]

Martijn Faassen wrote:
> Grok currently doesn't list its dependencies properly and even if we did 
> we'd pull in a huge part of Zope 3 (out of necessity).

I'm not sure what you mean by properly. Grok pretty much only depends on 
Zope 3 at this point (and the things it ships with: docutils, pytz, 
...). Until a few weeks ago, Zope 3 wasn't eggified completely so we 
couldn't simply depend on Zope 3.

I hope that now we can. In fact, I've been wanting to try this out.

> How do we accomplish this? One thing to do is to simply start listing 
> the dependencies in Grok's setup.py. But we also need to carefully 
> examine which dependencies Grok pulls in and try to minimize them as 
> much as possible (the ZMI..).
> 
> Then there are issues. Grok messes with Zope 3 security. We obviously 
> don't want people's security to be magically turned off if they install 
> a dependency that uses Grok.

In this case we need to differentiate Grok-the-configuration-system from 
Grok-the-web-framework which comes with its own publication object 
(which essentially is the heart of a Zope-based app server). You mention 
this split-up below.

I would advise, however, to keep the number of packages that we produce 
low. I would actually be fine with a 'grokcore' or 'groklib' package 
that contains the generic stuff and 'grok' that contains 
Grok-the-web-framework.

> To remedy both the 'vast number of dependencies' issue as well as the 
> 'Grok messes with my Zope' issue we could consider splitting Grok up 
> into multiple packages. We could for instance have a grokcore.component 
> that only defines Grokkers that use the pure component architecture, 
> such as adapter grokkers. This would allow those packages that only need 
> such Grokkers to only rely on this. We then have a Grok package that 
> depends on all grokcore packages that imports everything into the 'grok' 
> namespace package and adds Grok specific stuff like meddling with 
> security. Doing this will reduce the level of buy-in for people to use 
> Grok, and greatly enhances compatibility of Zope 3 and Grok. Someone can 
> use a package with interesting functionalities that uses 
> grokcore.component so that adapters are grokked instead of registered 
> with ZCML, and they might not even be aware of it until they examine the 
> code.
> 
> Finally we have the problem of when to start on this project. If we 
> start now, we make Grok dependent on an eggified version of Zope 3. 

I would have no problem with that.

> While I'm sure we want to do this soon, we don't want to break 
> everything now.

The first step we could do is make Grok depend on the Zope eggs and see 
how that works. As far as breaking things is concerned, you mentioned 
that the grok package would still provide a common imports for stuff 
from grokcore, so even here the breakage would be limited...

> This means this work will likely need to be done on a 
> branch for now. We shouldn't wait too long to start with this, as I 
> think Grok has much to gain from an eggified Zope 3 universe, and the 
> eggified Zope 3 universe from Grok.

Agreed. I think we should start this sooner than later.

+1 for a short-living branch.


-- 
http://worldcookery.com -- Professional Zope documentation and training