On Tue, Jan 08, 2013 at 08:02:56AM -0500, Jim Fulton wrote: > On Tue, Jan 8, 2013 at 7:45 AM, Marius Gedminas <mar...@pov.lt> wrote: > ... > > 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. > > It would work until someone added a new section at the end.
That's why I said "have the append-new-versions code append a [versions]
line if necessary"
> or
>
> If append-new-versions added a versions section
> if the last section wasn't a versions section, at which point
> you could end up with multiple versions sections spread
> over the file.
Yes. Better than appending version pins to an unrelated section, where
they would be silently ignored as unknown option values.
> Having buildout modify a hand-edited file just seems like
> a Bad Idea to me.
I think of it as a tool that helps me update a hand-edited file.
I haven't decided whether it's a good idea or a Bad Idea to have a
buildout.cfg do that updating automatically. Pros:
- whenever you add a new dependency, you'll get a pin for it, so you
never commit a version of a project with floating dependencies
Cons:
- if you decide that you want a certain dependency to float
(pinning distribute caused weird failures on my buildbot, so I kept
it floating), your buildbot keeps updating versions.cfg all the time
and you need explicit svn revert steps to avoid merge conflicts on
the next svn up.
Marius Gedminas
--
31337 is a prime number, go figure...
signature.asc
Description: Digital signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
