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

[Martijn Faassen]

Philipp von Weitershausen wrote:
> 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.

Of course. I didn't mean to imply we had done anything wrong. It's just 
that things are going ahead and Grok needs to fit in.

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

One thing I'd like to avoid is having the old 'whole Zope 3' approach 
next to the egg approach in a single buildout. While this might work 
(eggs for some tests, whole Zope 3 for the actual app serving), having 
two versions of the same code around would be quite confusing, so this 
is a situation I'd like to avoid.

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

There's also my old 'groklib' idea which just factors out the grokking 
process into a library, but doesn't rely on anything in Zope at all. I'd 
like to reserve the name 'groklib' for that.

I'd still propose grokcore to be a namespace package. For testing 
purposes I'd really like a grokcore.component that only dealt with the 
core component architecture and didn't need to import anything from, 
say, formlib, or zope.app.

This is in fact the concrete use case that drove this thinking. Having 
grokcore.component will help us with compatibility. If I release a new 
Zope 3 component that grokked its adapters (and only that), people would 
be much more likely to start using it if it didn't pull in the whole of, 
say, zope.app. Such a component would be functionally equivalent to a 
Zope 3 package with the equivalent ZCML.

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

Yes, but we can't do it with the trunk, and the ability to run the whole 
Zope server from eggs is very new right now.

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

Okay! Now we need the time and energy to try this!

Regards,

Martijn