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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
