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

[Martijn Faassen]

Philipp von Weitershausen wrote:
> On 25 Apr 2007, at 16:24 , Martijn Faassen wrote:
[snip]
>> 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.

Don't you think that's going to make it even harder to maintain?

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

grok.skip can be used to basically hack your way out of trouble. A 
package doesn't provide for you selectively disabling things, but you 
know what you're doing and you just turn things off selectively. If the 
package changes, your skip might easily break. It requires detailed 
knowledge of package internals to use.

grok.tag is a public contract made by the package author. That is, 
grok.tag is not useful at all if the author of a package doesn't tag 
things. The package author needs to promise to maintain the tags. Then 
you can go say, I only want to grok things in this package that are 
tagged such and such, or not tagged such and such.

As an example of a use case, if Zope 3 were made with grok, and all the 
browser views were tagged, we could use Zope 3 without its UI as we 
want. We would not have to worry about maintaining a large amount of 
skip instructions and having it break every once in a while, as Zope 3 
would be taking care of this.

With an open source package that you want to disable something on, you 
probably should choose to talk to the author and add a few selective 
tags on things. Only if you are in a hurry, or can't talk to the author, 
or if it's really just a single thing you want to disable, should you 
resort to grok.skip.

This is why I said they are two separate use cases. I think we need to 
consider adding both.

Note that we could even consider automatically tagging things that are 
grokked. If we knew all browser views are tagged, we could grok a 
package except for its views. So you could say: I want to grok only the 
adapters in this package. Or "everything but not the subscriptions".

grok.tag can also serve a role for marking tests. The main grokker would 
know it shouldn't grok tests. The test runner would (somehow) know that 
it should grok the package *including* the tests.

Regards,

Martijn