[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