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

[Marius Gedminas]

On Mon, Jan 07, 2013 at 05:51:56PM -0500, Jim Fulton wrote:
> On Mon, Jan 7, 2013 at 9:57 AM, Marius Gedminas <marius at pov.lt> wrote:
> > On Mon, Jan 07, 2013 at 09:45:58AM -0500, Jim Fulton wrote:
> >> No.  The versions-file can be used with the existing mechanism.
> >> I tried, but apparently failed, to make this clear in the proposal.
> >>
> >> If both a versions file and a versions section is used, the versions
> >> section behaves as it does now and versions in the versions file
> >> override versions specified in the versions section.
> >
> > This seems backwards to me.
> >
> > Consider this example
> >
> >     $ cat buildout.cfg
> >
> >       [buildout]
> >       I-forgot-the-suggested-new-spelling-for-a-versions-file = versions.txt
> >       parts = ...
> >
> >       ...
> >
> >     $ cat mg.cfg
> >
> >       [buildout]
> >       extends = buildout.cfg
> >       versions = versions
> >
> >       [versions]
> >       SomePackage = overridden_version
> >
> > I would expect bin/buildout -c mg.cfg to use my overridden version from
> > mg.cfg, not the one from versions-file.txt.
> 
> So would you be happy if the version from mg.cfg overrode the
> version from the versions file?

Yes.

I often do use this trick because 'develop = ../src/zc.foo' tends to be
ignored when zc.foo is pinned to version 1.2.3 in my versions.cfg,
unless I add an empty 'zc.foo =' version pin to my temporary
dev.cfg/mg.cfg whenever I want to test a bugfix for zc.foo.

> > Also, having two similar but slightly distinct mechanisms for version
> > pinning?  I'm -1 on that.
> 
> In an earlier message, you wrote
> 
> > If you also add
> >
> >   buildout_versions_file = versions.cfg
> >
> > it'll append new version pins to versions.cfg with the versions that
> > are picked while you run bin/buildout.  It's not smart -- you have to
> > ensure the file you're writing to ends with a [versions] section, and
> > that your mail buildout.cfg specifies `extends = versions.cfg` and that
> > you have `[buildout] versions = versions` in either of the config files.
> 
> This sounded like a complaint to me.

It wasn't meant to be that way: I was merely trying to describe the
behaviour.

> It seemed like a lot of things
> you had to know and get right to use the mechanism.

I agree that the bootstrapping process is a bit tedious, but there are
redeeming features (using the same extends mechanism makes it composable
and easy to reason about).

If backwards-compatibility weren't an consideration, I'd be tempted to
have buildout 2.0 hardcode the versions section name to [versions] and
have the append-new-versions code append a "\n\n[versions]\n" line if
necessary.

That way you could say

  [buildout]
  append-picked-versions = buildout.cfg

and have it Just Work with no extra bootstrapping.

> Maybe I read too much into what you wrote.

I'm not as good at communicating as I would like to be.

> The version-file option tries to simplify the process.  For the
> large percentage of cases where you don't care about known-good sets
> or layered configurations, it's the only mechanism you need.
>
> If we had version-file, then the version option would become the
> advanced option used when you do need to layer configurations.

I see your point, but I fear that having two options (simple and
complex) is more complicated than having just one (complex).

Marius Gedminas
-- 
You'll find creativity working hand in hand with engineering. It will feel
strange and you might feel like things are out of control. Relax - they are.
		-- Richard Gabriel on software
		   http://www.dreamsongs.net/LessonsFromNothing.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130108/135604a2/attachment.pgp>