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

[Jim Fulton]

On Sun, Jan 6, 2013 at 7:38 PM, Alex Clark <aclark at aclark.net> wrote:
> On 2013-01-05 22:47:05 +0000, Jim Fulton said:
...
>>
>>   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].

That would make the section named "version" reserved.
This would be backward incompatible, which is why I didn't
do it that way to begin with.  Of course, buildout 2 provides
an opportunity to change things in a backward-incompatible
way.

...

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

The proposal augments the current machinery.  You will
still be able to define a versions section.

> (At the very least, I'd
> make Buildout always use versions specified inside a [versions] section i.e.
> by making "versions = versions" the default.)

As mentioned above, this would be backwards-incompatible,

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

It doesn't encourage them to pin versions, it just
makes it easier.

> To give some real world
> context, IIUC I can create a buildout:
>
>  [buildout]
>  update-versions-file = true
>  parts = zope2

This would be an error, since you haven't
specified a versions file.

Also, I don't expect people to set update-versions-file in their
buildout.cfg, but rather to turn it on via a command-line argument.

>  [zope2]
>  recipe = zc.recipe.egg
>
>
> If I run this, I'll get a versions.txt file

If you also included:

versions-file = versions.txt

in your buildout section.

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

In the example above, the versions.txt file would include versions for
Zope2 and all its dependencies.

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm