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

[Jim Fulton]

On Sat, Jan 12, 2013 at 11:18 AM, Jim Fulton <jim at zope.com> wrote:
> On Sat, Jan 5, 2013 at 5:47 PM, Jim Fulton <jim at zope.com> wrote:
> ...
>> I propose that buildout-versions get incorporated into
>> buildout in the following way:
>
> OK, proposal 1 wasn't accepted.  Here's another stab:
>
> Proposal 2
> ----------
>
> 1. The ``allow-picked-versions`` option gets a new allowed value of
>    ``show``. if there are unpicked versions and this option is set to
>    ``show``, then picked/unpinned versions are reported in a way
>    suitable for copying into a versions section, presumably with the
>    same format used by buildout-versions today.
>
> 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.

OK, so this turned out to be controversial. Some people want
a variation on the current behavior (versions rule) but with
an error if a develop version doesn't match.

Others would like to use a develop egg even if it doesn't
satisfy a version constraint from the versions section.

So:

Let's:

- Exclude this from the proposal.

- As a separate project (at some time), add an error
  check for develop eggs that are ignored because
  they don't satisfy a version constraint from the versions
  section.  I'll consider this a bug fix, or at least not
  a backward incompatibility.

- As yet another possible project, add an option to
  ignore version constraints (from the versions section)
  for develop eggs.

Note that none of the above says anything about version
requirements of individual distributions.  It only applies
to version requirements given in the versions section.

>
> 5. In buildout 2, The default value of the versions option will be
>    "versions", rather than being unset. This will allow users to
>    omit::
>
>       version = versions
>
>    from their buildout section.

I'll do this in 2.0.

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

I'll do this in 2.0 as well.

So I think we're in agreement (as much as feasible).

I'll do 5 and 6 in buildout 2.0.  Hopefully, I can get a beta out
this weekend.

1, 2, and 3 will be done when Chris (or someone else) makes
time to work on a pull request.  Perhaps this will be in buildout 2.1.

Jim

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