On Sat, Jan 12, 2013 at 11:18:36AM -0500, Jim Fulton wrote: > On Sat, Jan 5, 2013 at 5:47 PM, Jim Fulton <j...@zope.com> 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.
+0.5 (the missing 0.5 is for aesthetic reasons, but I have no better suggestions at the moment, and besides bikeshedding on this would be counter-productive) > 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). +1 > 3. New buildout option: ``python-version`` that restricts the Python > version, with the same semantics as buildout-version provides now. +1 > 4. Change: develop eggs found in the buildout's develop-eggs directory > will be used even if their version conflicts with a pinned version. +1 for the intent, -1 for the implementation. To me develop-eggs was always some kind of mystical implementation detail that sometimes broke things (leftover egg-link files even after I removed those names from my 'develop =' list and re-ran bin/buildout; which always occurred at a point in time when my internal stack was full and I couldn't investigate/file bugs and just rm-rf'ed develop-eggs to be able to continue). I suggest this instead: develop eggs explicitly listed in the [buildout] 'develop' options will be used even if their version conflicts with a pinned version. > 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. +1, assuming that was a misspelling of 'versions = versions'. (Corner case analysis: I expect that 'versions = ' will turn off version pinning. I've no intention of ever making use of that corner case) > 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.) +0.5 (gut feeling: I like this. I haven't had time to think about the possible consequences, so I'm withholding the other 0.5 for now.) (Aside: I always wanted buildout to have --newer and --not-newer, because I cannot for the life of me remember which is -n and which is -N. Being able to say bin/buildout newer=off would relieve that need considerably.) Marius Gedminas -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth
signature.asc
Description: Digital signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig