On Mon, Jan 07, 2013 at 05:51:56PM -0500, Jim Fulton wrote: > On Mon, Jan 7, 2013 at 9:57 AM, Marius Gedminas <mar...@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
signature.asc
Description: Digital signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
