On Sat, Jan 12, 2013 at 11:18 AM, Jim Fulton <[email protected]> wrote: > On Sat, Jan 5, 2013 at 5:47 PM, Jim Fulton <[email protected]> wrote: > ... >> I propose that buildout-versions get incorporated into >> buildout in the following way: > > OK, proposal 1 wasn't accepted. Here's another stab: > > Proposal 2 > ---------- > > 1. The ``allow-picked-versions`` option gets a new allowed value of > ``show``. if there are unpicked versions and this option is set to > ``show``, then picked/unpinned versions are reported in a way > suitable for copying into a versions section, presumably with the > same format used by buildout-versions today. > > 2. New buildout option: ``update-versions-file``. This takes a path > (relative to buildout directory) of a file to update with any > unpinned versions (in a manner roughly the same as > buildout-versions does today). > > 3. New buildout option: ``python-version`` that restricts the Python > version, with the same semantics as buildout-version provides now. > > 4. Change: develop eggs found in the buildout's develop-eggs directory > will be used even if their version conflicts with a pinned version.
OK, so this turned out to be controversial. Some people want a variation on the current behavior (versions rule) but with an error if a develop version doesn't match. Others would like to use a develop egg even if it doesn't satisfy a version constraint from the versions section. So: Let's: - Exclude this from the proposal. - As a separate project (at some time), add an error check for develop eggs that are ignored because they don't satisfy a version constraint from the versions section. I'll consider this a bug fix, or at least not a backward incompatibility. - As yet another possible project, add an option to ignore version constraints (from the versions section) for develop eggs. Note that none of the above says anything about version requirements of individual distributions. It only applies to version requirements given in the versions section. > > 5. In buildout 2, The default value of the versions option will be > "versions", rather than being unset. This will allow users to > omit:: > > version = versions > > from their buildout section. I'll do this in 2.0. > 6. To make it a little easier to supply buildout versions on the > command line, make buildout the default section for command-line > options, so:: > > update-versions-file=versions.cfg > > or:: > > allow-picked-versions=show > > would be allowed. (They are rejected now.) I'll do this in 2.0 as well. So I think we're in agreement (as much as feasible). I'll do 5 and 6 in buildout 2.0. Hopefully, I can get a beta out this weekend. 1, 2, and 3 will be done when Chris (or someone else) makes time to work on a pull request. Perhaps this will be in buildout 2.1. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
