[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