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

[Martijn Faassen]

Hey,

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. :)

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.

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()'?

> 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. 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. :)

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.

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.

Regards,

Martijn