[Distutils] Proposal for incorporating buildout-versions on buildout (Re: Better version pinning in buildout (buildout-versions))

[Marius Gedminas]

On Sat, Jan 12, 2013 at 11:18:36AM -0500, Jim Fulton wrote:
> On Sat, Jan 5, 2013 at 5:47 PM, Jim Fulton <jim at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130113/e40a3c6b/attachment.pgp>