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

Jim Fulton jim at zope.com
Mon Jan 7 15:42:58 CET 2013

On Mon, Jan 7, 2013 at 6:12 AM, Maurits van Rees
<m.van.rees at zestsoftware.nl> wrote:
> Op 05-01-13 23:47, Jim Fulton schreef:


>> 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.

Why?  A makor point of this proposal is that it isn't a buildout
configuration, so it doesn't need a header and you don't have to use a
buildout section.  You still *can* have a buildout section, which the
buildout-file augments, ut you don't have to.

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

No, because it's not a buildout configuration file.

> 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.

This would still be supported.


>> 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

No, as described in the proposal, if update-versions-file is true (and
assuming that you've specified a versions-file) then there would not
be an error if allow-picked-versions was false and there were picked
versions, because they'd be added to the versions file and thus
would become un-picked.

> warn       false       buildout reports versions on stdout

Yes, in a format convenient for copying into a versions configuration
or versions file.

> 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?



Jim Fulton
Jerky is better than bacon! http://zo.pe/Kqm

More information about the Distutils-SIG mailing list