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.

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:
   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. :)



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

Reply via email to