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

Alex Clark aclark at aclark.net
Mon Jan 7 01:38:40 CET 2013

On 2013-01-05 22:47:05 +0000, Jim Fulton said:

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

This is confusing… but I was thinking more along the lines of adding a 
default setting "versions = versions", at which point end users need 
only to add a section named [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.

+0 And if you do this, it may cause confusion with folks familar with 
the current practice. Is it possible to support both? (At the very 
least, I'd make Buildout always use versions specified inside a 
[versions] section i.e. by making "versions = versions" the default.)

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

So this helps encourage folks to pin versions by auto-generating the 
versions file and using it on subsequent runs? To give some real world 
context, IIUC I can create a buildout:

  update-versions-file = true
  parts = zope2

  recipe = zc.recipe.egg

If I run this, I'll get a versions.txt file with ZTK packages in it 
(but not necessarily the packages required to run Zope2, since Zope2 
itself does not know about its own KGS i.e. 
http://download.zope.org/Zope2/index/2.13.19/versions.cfg. And 
subsequently PyPI will return the latest version of each 
install_requires value.)

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


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

Meaning I can't bootstrap a Plone 4 buildout with Python 2.4 nor a 
Plone 3 buildout with Python 2.7? If so, +1.

> Thoughts? Did I miss anything?
> Jim

Alex Clark · https://www.gittip.com/aclark4life/

More information about the Distutils-SIG mailing list