[Grok-dev] Re: z3c.widget.tiny, resourceLibrary and automatic load of resources

Martijn Faassen faassen at startifact.com
Wed Jan 16 00:48:10 EST 2008


Hey,

Tres Seaver wrote:
[snip]
> Just for the record, I'm opposed to automagically registering ZCML (and
> therefore policy) from a package, just because I happen to import
> something from the package.

I know; it's already on the record. You're not the only one who thinks 
that way.

>  If you do this, it should be in terms of an
> explicit directive (e.g., in the genereated site.zcml) with a big XML
> comment explaining why the directive is there:
> 
>  <!-- Enabling this directive causes implicit loading of ZCML
>       from "dependency" packages;  you may need to disable it
>       if you find that one or more of the policies in those files
>       don't suit. -->
>  <dwim-zcml />

I don't really like this approach either as the control isn't very 
granular (and the control is ZCML).

> Now, if you are shipping an application which sets up an "instance" of
> some sort, you should of course feel free to wire up whatever ZCML is
> needed by that application in the context of that instance.  Just don't
> assume that the presence on sys.path of a package containing ZCML
> implies that we should load it.

Presence on sys.path is something different than having a dependency 
being present in setup.py. I think we should try to go for an approach 
that uses this dependency information instead of simply scanning 
sys.path (you seem to say so earlier, this makes me think your approach 
involves scanning sys.path. Then again, scanning sys.path might be the 
simplest way to implement this behavior; I'm not sure).

I can't see a way to fulfill both requirements: reduce doing things in 
multiple places *and* not doing this by default. That's why my 
conclusion is that we should make what I believe *is* the common case 
(include a package's ZCML) the default behavior.

I'd like there to be a way to say: I want to depend on this package, but 
*not* on any of its ZCML. I.e. a way to turn off the default. I'd like 
that to be more granular than saying it for *all* packages.

There's the ZCML exclude extension that might serve this purpose; I'm 
not sure. (Similarly we eventually need more fine-grained ways of 
grokking - a way of saying, "I want to grok this codebase, but *don't* 
grok this and that.")

Unfortunately I don't know of good ways to express things like this in 
setup.py. It'd be nice if we had dependency meta information, i.e. not 
just what we depend on, but also how we want to depend on it.

Regards,

Martijn



More information about the Grok-dev mailing list