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

[Philipp von Weitershausen]

Martijn Faassen wrote:
>> 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.

Naturally. Fortunately Zope 3 is at a point where we can install a whole 
Zope 3 application (including Zope 3 itself) from eggs (see baijum's 
zwiki branch for an example).

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

Ok, fair enough.

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

Ok, as long as

* the 'grok' package makes all that default stuff available

* the documentation doesn't confuse users with a gazillion different
   packages with slightly different naming. What I'm trying to say is
   that the docs should also *advise* importing things from 'grok'.

I guess I'm preaching to the choir here anyway... :)

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

Not sure what you mean here.

> and the ability to run the whole Zope server from eggs is very new
> right now.

True, but if it works... :)


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