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

[Martijn Faassen]

Jim Fulton wrote:
> 
> On Apr 23, 2007, at 2:43 PM, Martijn Faassen wrote:
> ...
>> 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.
> 
> Except that the information belongs in your application package's 
> configure.zcml.  site.zcml should, IMO, be a very short file that
> include's your application package's configure.zcml.  If you want to 
> write a tool that writes your configure.zcml, go for it.

> I wouldn't object to a zcml configuration directive that took a project 
> name and included zcml files provided by it's dependencies at run time.

Yes, that would be useful. I will think about it. Preferably it should 
be somewhat ZCML independent so Grok can make use of it too.

>> 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.
> 
> You could argue that the dependencies in setup.py duplicate information 
> in your Python import statements -- if you wanted to.

Good point, but I don't want to argue that. :) Anyway, automating egg 
dependencies from import statements is somewhat harder as some 
information is missing (egg name, version requirements). An interesting 
project. :) Not urgent, though.

I realize I'm quite active in looking for points of duplication to 
reduce. I don't think it's a bad exercise for any framework to do this.

[snip]
>> 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".
> 
> The default behavior is to update all packages to the most recent 
> version that satisfies your requirements.  This means that running 
> buildout in 2 different buildouts with the same configuration should 
> produce the same results, regardless of their history.  I think this is 
> an important property that you lose with -N.

Ah, understood. I hadn't thought of this in the context of multiple 
buildouts, but that's of course an important property for team 
development situations.

>>>  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.
> 
> That's why I suggested putting it in: ~/.buildout/default.cfg, which 
> would effect only you.

Ah, I should read more carefully, sorry. I should also look up the 
explicit option to turn on newest again to make sure I can develop as 
part of a team. :)

Regards,

Martijn