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:
[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.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
