[Distutils] Better version pinning in buildout (buildout-versions)
jim at zope.com
Mon Jan 7 15:33:46 CET 2013
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
> 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
>> 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
>> # 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:
> 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.
> 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.
Jerky is better than bacon! http://zo.pe/Kqm
More information about the Distutils-SIG