[Grok-dev] Re: skipping modules during grokking process

[Philipp von Weitershausen]

On 25 Apr 2007, at 16:24 , Martijn Faassen wrote:
> On 4/25/07, Philipp von Weitershausen <philipp at weitershausen.de>  
> wrote:
>> Martijn Faassen wrote:
> [proposes a module-level grok.testfixture()]
>
>> Sorta. I would really like to see a way to tell Grok to NOT grok a
>> certain package/module/component from the *outside*.
>> This way you can
>> easily customize and switch off things that come from 3rd party code.
>> ZCML has overrides but those are unsatisfactory when you just want to
>> switch something off (e.g. an event subscriber). I've had and  
>> heard this
>> use case often.
>
> This sounds useful, but is somewhat distinct from the testfixture use
> case. Perhaps your 'sorta' acknowledges that. :)

Heh, prolly :)

> The testfixture use case is a way to say internally in a module that
> it should only
> be grokked at testing-time, but not at run-time. It only contains
> things that should be registered during the test run (mock adapters
> and such). This means that they *will* be grokked during tests.

Right. Does it make sense to simply come up with naming conventions  
for such modules instead of/in addition inventing another directive?

> It's possible we will need to distinguish between test fixtures as
> well, in which case we perhaps can introduce some form of tagging
> scheme (interface based?). This is a possible generalization which
> allows the developer to tag specific modules and classes. The grokking
> logic can then say "grok everything, except tagged by this" or "grok
> only things tagged that way". This would allow for instance the
> marking of anything view-specific with a tag and someone can then
> still reuse the package except for the views. This leads into your use
> case:
>
>> My idea was to come up with a grok.dont_grok() directive. It would  
>> take
>> either a component or a dotted name:
>>
>>    grok.dont_grok('this.module.or.package')
>>
>>    grok.dont_grok(someEventSubscriber)
>
> What about spelling this 'grok.skip()'?

Much better :)

>> Having configuration actions from Python would be a nice to have for
>> this, but not required. If we had actions, we would be able to  
>> specify
>> the grok.dont_grok() directive anywhere; there wouldn't be any order
>> necessary because Grok would first compute all the actions and then
>> cancel those out that are unwanted. For now (no actions),
>> grok.dont_grok() could simply be order-dependent and only  
>> influence the
>> things that Grok *will* grok.
>
> That does imply that there is a known order in which modules get
> grokked, something we currently don't have at all.

Sure we do. The known order is the order in which you call grok.grok 
() or invoke the <grok /> directive.

> What about avoiding this trouble and grokking
> for skip information first and only then doing the main grok run? More
> expensive, but far more easy to implement solidly. Actions would  
> indeed be even
> better. I suspect we can stop waiting for Zope 3 to evolve
> Python-level actions without our help, by the way. :)

Hmm, yeah.

> Note that this use case is subtly different from the tagging one.
> grok.skip() is for people who understand quite well what codebase they
> are grokking. They can mark exactly what they don't want. grok.skip
> has a maintenance cost, as when the codebase changes, the skipping
> logic can easily break.

It might be tolerant wrt no longer existing things when you use  
dotted names to refer to them.

> grok.tag() (or whatever we call it) is different. It is a contract
> maintained by the author of a package, so deep knowledge about the
> internals of a package is not necessary in order to control grokking
> behavior. Maintenance risk for people relying on it is therefore
> lower. Maintenance cost for the package developer is a bit higher as
> they will need to maintain the tags.
>
> I think both are useful. I think grok.tag() would be the encouraged
> case, and grok.skip() would only be for emergencies.

I'm not sure I fully understand your the idea berhind grok.tag(). It  
seems to somewhat fit the test fixture use case you have, but I don't  
see how I can easily manipulate somebody else's registrations.  
Sometimes I just want to turn off that one subscriber or that one  
adapter. Could you spell out how grok.tag() would help me there?  
Also, what other concrete use cases do you see for grok.tag()?