[Distutils] Better version pinning in buildout (buildout-versions)

[Maurits van Rees]

Op 05-01-13 23:47, Jim Fulton schreef:
> Lots of people agree that buildout-versions us useful
> and the author has volunteered to contribute it to core buildout.
>
> Cool!
>
> Of course, as a part of buildout, rather than an extension, it can be
> streamlined a bit. Also, based on experience, I think we can simplify
> versions management a bit further.
>
> When I implemented the versions mechanism in buildout, I decided to
> build on the configuration model.  This has worked pretty well,
> especially for complex use cases like layering version specifications
> (e.g. building on "known good sets"), but this approach has added a
> little bit of drudgery.  Because I didn't want to stomp on existing
> versions sections, I made the name of the section containing versions
> require configuration, which means you end up with::
>
>    versions = versions
>
>    [versions]
>    ...
>
> I also think it's a little awkward to have buildout update files that
> are also edited by users.
>
> Based on this, I propose that buildout-versions get incorporated into
> buildout in the following way:
>
> 1. New buildout option named ``versions-file`` which takes the name of
>     a file. to contain version information.  It is not a configuration
>     file.  It is a file consisting of comments (#...)  and version
>     specifications::
>
>       # whatever
>       foo = 1.3
>
>     If it doesn't exist, it wil be created.  (I'm not sure it's a good
>     idea to create the file implicitly though.) Any version constraints
>     found in the file are added to the buildout version constraints.
>     Version constraints found in the versions-file override version
>     constraints obtained via a versions option, if any.

A section header should be permitted too, specifically '[versions]', so 
it is just a normal buildout file.

Would this file be implicitly added at the end of the 'extends' list? 
Or would the user still need to do that explicitly.

I always just let buildout-versions or buildout.dumppickedversions print 
the picked versions and when I agree I paste them in versions.cfg or 
another buildout file.

> 2. New buildout option: ``update-versions-file``. If this is true,
>     then any picked/unpinned versions are appended to the versions file
>     and reported in the output. There's a command-line option, ``-V``
>     to set this to true for a run.  It's an error to use this if
>     ``versions-file`` isn't set.

+0.  I would probably not use this bit, but some people do use it in the 
current extensions.

> 3. The ``allow-picked-versions`` option gets a new allowed value of
>     ``warn``. if there are unpicked versions and this option is set to
>     ``warn``, then picked/unpinned versions are reported.  Also, if
>     ``allow-picked-versions`` is true, there will be no error if
>     ``update-versions-file`` is true.

+1.  In a development setup I would probably set this to 'warn' and in 
production to 'false'.

Say there is a buildout config with one or more versions that are not 
pinned.  What would the effect be of the various options?  Here is a 
truth table:

allow-p-v  update-v-f  result

false      false       buildout quits with error

false      true        buildout quits with error

warn       false       buildout reports versions on stdout

warn       true        buildout edits versions file

true       false       buildout reports versions on stdout

true       true        buildout edits versions file

 From that, I wonder if there is a practical difference between 
allow-picked-versions being set to 'warn' or 'true'.  Perhaps when it is 
true and update-versions-file=false (row 5), you do not want to print 
anything?

> 4. New buildout option: ``python-version`` that restricts the Python
>     version, with the same semantics as buildout-version provides now.

+1


-- 
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl