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.

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.

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".

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.

It is easy for people to change the default for their own use by putting:
   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.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to