[Distutils] Better version pinning in buildout (buildout-versions)
marius at pov.lt
Tue Jan 8 13:45:01 CET 2013
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?
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
> 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
That way you could say
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).
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: Digital signature
More information about the Distutils-SIG