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

Philipp von Weitershausen philipp at weitershausen.de
Wed Apr 25 06:09:00 EDT 2007


Martijn Faassen wrote:
> We need to be able to control the grokking process a bit better. Certain 
> modules contain code that should only be loaded for testing purposes for 
> instance. These modules should be skipped during the normal grokking 
> process, but loaded when we test the package.
> 
> We might be able to do accomplish this with a grok.testfixture() 
> directive on module-level. If this directive is present, the module will 
> be skipped by Grok during the normal grokking process. If the grokking 
> process is happening in a special testing mode, it will not be skipped.
> 
> Perhaps some generalization of this system is possible, though I'm not 
> sure whether that's desirable at this stage. Do we have other use cases 
> for skipping modules besides testing?

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.

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)

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.


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


More information about the Grok-dev mailing list