[Grok-dev] Re: static versus Zope 3's directory resources

Philipp von Weitershausen philipp at weitershausen.de
Mon Nov 26 12:58:59 EST 2007

Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>> Wichert Akkerman wrote:
>>> Previously Philipp von Weitershausen wrote:
>>>> Jan-Wijbrand Kolman wrote:
>>>>> Philipp von Weitershausen wrote:
>>>>>>> (personally I think it could very well be in Grok itself.)
>>>>>> Both :).
>>>>> :)
>>>>>> I think we want to split up Grok for it to be more modular. This is a 
>>>>>> perfect example of a single, self-contained piece of functionality 
>>>>>> that makes sense to be shipped with *and* without Grok.
>>>>>> I would personally like to tackle to split-up of Grok pretty soon. 
>>>>>> I've done an experiment a while back already and it worked well. The 
>>>>>> lessons learned have been incorporated into the 0.11 release already. 
>>>>>> My plans are to start with splitting off the ZCML directive 
>>>>>> implementation and the registration of core components (adapters, 
>>>>>> utilities, subscribers) before the year is over...
>>>>> So, as a practical result of the split, you could imagine to have a 
>>>>> "grok.resources" package at some point?
>>>> Right. We can't make 'grok' a namespace package, though, because it 
>>>> contains code in __init__. We'll have to use something else. Martijn 
>>>> wants to use grokcore.
>>> Is this really tied to grok? It sounds like it could just as well be a
>>> z3c.* thing.
>> It's grok specific in the sense that it exposes already existing 
>> functionality (in zope.* packages) in a grokkish kind of way. Sure, it 
>> could all be a z3c.* thing, even grok could've been z3c.grok, but I 
>> don't think we want to go there.
> Isn't 'martian' already a 'grokcore'-like namespace package?

martian isn't a namespace package. It's a package with code in it, hence 
unusable as a namespace package.

More information about the Grok-dev mailing list