[Grok-dev] Re: skipping modules during grokking process
faassen at startifact.com
Wed Apr 25 16:21:28 EDT 2007
Philipp von Weitershausen wrote:
> On 25 Apr 2007, at 16:24 , Martijn Faassen wrote:
>> 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.
More information about the Grok-dev