[Distutils] Proposal for incorporating buildout-versions on buildout (Re: Better version pinning in buildout (buildout-versions))

[Jim Fulton]

On Sat, Jan 12, 2013 at 3:42 PM, Alex Clark <aclark at aclark.net> wrote:
...
>> 2. New buildout option: ``update-versions-file``.  This takes a path
>>    (relative to buildout directory) of a file to update with any
>>    unpinned versions (in a manner roughly the same as
>>    buildout-versions does today).
>>
>> 3. New buildout option: ``python-version`` that restricts the Python
>>    version, with the same semantics as buildout-version provides now.
>>
>> 4. Change: develop eggs found in the buildout's develop-eggs directory
>>    will be used even if their version conflicts with a pinned version.
>
>
> Did somebody ask for this? I tend to think of develop eggs as "real" eggs.
> So if I want to resolve a conflict I'll just edit the develop-egg
> (presumably by changing the version of the develop egg in the case of a
> non-develop-egg that requires a particular version of a develop egg.)

Well, theres:

http://packages.python.org/buildout-versions/use.html#development-packages

which, rereading it, isn't quite the same thing.

Martijn Faassen used to argue with me about this, that
if you're developing something in a buildout, it should be used.
I've come to think he was right.

A challenge is that eggs are often classified as "develop" eggs by
setuptools even though they aren't used for development.  Eggs
installed via system packagers are often installed this way.
Thus, the requirement that only eggs that show up in a buildout's
develop-eggs directory should be used even if they are pinned.

...

>> 6. To make it a little easier to supply buildout versions on the
>>    command line, make buildout the default section for command-line
>>    options, so::
>>
>>       update-versions-file=versions.cfg
>>
>>    or::
>>
>>       allow-picked-versions=show
>>
>>    would be allowed. (They are rejected now.)
>
>
>
> So that means I can pass in foo=bar and it will be applied to the buildout
> section? How about allowing parameter/values to be applied to any section
> and defaulting to buildout? E.g.:

That's what I'm proposing.

You can currently supply an option in any section
with sectionname:optionname=value.  The proposal
is to allow the section name to default to buildout.

>
>    $ buildout buildout:update-versions-file=versions.cfg
>
> Is this same as:
>
>    $ buildout update-versions-file=versions.cfg

Yes

> But I can also do:
>
>    $ buildout foo:bar=baz
>
> To set parameter 'bar' with value 'baz' in section 'foo'.

You can do this today.

Jim

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