[Zope3-dev] Re: Autoconfiguring a site.zcml

[Martijn Faassen]

Jim Fulton wrote:
> 
> On Apr 23, 2007, at 2:14 PM, Martijn Faassen wrote:
[snip]
>> As far as I can determine from this thread (I have some difficulty 
>> following parts of David's long mail as well) you two are agreeing. :)
>>
>> Jim, is it correct that you'd like the zope 3 recipe to grow an option 
>> to auto-construct a site.zcml based on egg dependencies?
> 
> No.  I suggested that packages that have ZCML and that depend on other 
> packages that have ZCML should include the ZCML of the packages they 
> depend on.  If this was common practice, then I don't think that 
> constructing a site ZCML would be that hard.

It'd be a lot easier. You'd still have to list it for all eggs that you 
depend on directly. It would be nice if this could be automated as well, 
as being in two places to add a single dependency is more work than 
being in one place. Could be done with a special recipe, I think.

Package-level ZCML include dependencies would also mean a kind of 
duplication, too. You list dependencies in setup.py and then again in 
the package's ZCML. This is tolerable in most cases though. It wouldn't 
work for a Grok based package depending on any external packages, but 
that's Grok's problem.

>> Tres's argument is that since there is no system to override ZCML 
>> auto-inclusion of configuration should not be implemented yet. But Jim 
>> seems to disagree with this (and I do too).
> 
> There isn't a good way to cancel configuration done by included 
> packages.  I've found that in practice this usually doesn't matter, but 
> I agree with Tres that it is a significant hole.

Yeah, I agree with you that it usually doesn't matter, and I agree with 
Tres that it is a significant hole. Where Tres seems to disagree with 
you and me is that he doesn't want people to include ZCML.

>> I also don't understand David's problem with buildout times. The 
>> option -N helps a lot. Jim, is there anything to say for actually 
>> making -N the default behavior of buildout?
> 
> No, But I can say something against it. :) Making it the default would 
> make buildout's default behavior less deterministic.

I don't understand.

I can see how -o is the most deterministic buildout behavior, as it will 
upgrade nothing. The next step in my mind would be -N, as it only 
installs what's not there yet. Finally there's "no option", which is 
least predictable it might start updating stuff, depending on what 
package restrictions you have. Obviously I'm not understanding what you 
mean by "deterministic".

I just find myself typing -N a lot, and get annoyed when I forget it.

>  It is easy for 
> people to change the default for their own use by putting:
> 
>    [buildout]
>    newest = false
> 
> in their ~/.buildout/default.cfg file.

Ah, a trick I wasn't aware of. I will do that then in my buildout.cfgs, 
though this will indeed might cause a few surprises to people they might 
get used to it and be surprised when they need -N in other buildouts.

Regards,

Martijn