Previously Christophe Combelles wrote: > David Pratt a écrit : > >Hi. I agree with Jim. Buildout is doing the right thing. This is not a > >conflict since you have explicitly identified the software with a > >version already. I think the right thing to do under the circumstances > >would be to append a custom versions.cfg to nail the versions you want. > >KGS versions is a point in time list and it does not apply to the full > >scope of what buildout is being used for. I believe this should be kept > >in mind since it serves more than z3. > > > >Changes to buildout to have it automatically do the 'right' thing opens > >the implicit versus explicit argument. A developer would then need to be > >aware of the implicit cases that would cause a different software > >selection. Much like zcml configuration in zope, I want to tell buildout > >what to do and have it do it without surprise (or for that matter > >fighting any implicit nature folks may be inclined to give it). While I > >understand the concern about the development egg for your build, I would > >see any move in this direction as corrupting the nature of buildout to > >'do what you have told it to do'. > > > Hi, > > I don't think this is a matter of implicit versus explicit, because there > are two explicit configurations: one explicit 'version', and one explicit > 'develop'. > I think the question is about what to choose between two explicit > configurations that are potentially conflicting.
I'ld disgraee. To me 'develop=' is just a way to tell buildout that it can also use a local development egg in addition to everything it can find on remote indexes. It just extends the list of places where packages can be found but does not change any rules for selecting the version to use. It's perfectly possibly to have a local development egg with an exact revision number which you select in a version part in buildout.cfg. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )