[Distutils] buildout: supporting += and -= in <=-style extends
Vincent Pelletier
vincent at nexedi.com
Tue Feb 21 10:22:57 CET 2012
Hi.
To properly factorise a .cfg I write, I use <=-style section extension.
Some of the properties I define would take advantage of += operator, but
"[buildout]\nextends = ..."-style extension.
Wouldn't it be convenient if it worked internally to a file as well ?
I've poked around in the code, and found that it's not trivial to implement
(calling existing _update_section function is not enough, as that calls
"update" on its first parameter and expects values to be pairs).
Also, it would create ambiguous outcome when a section would contain <= and
its file would extend another file containing an homonym section...
Do anyone have an idea of how to implement this feature ?
The best I could come up with is based on doubling "+" or "-" (rightmost is
for "[buildout]\nextends = ..." extension when used, leftmost is for
"<="extension) when used. The outcome looks logical enough, but I'm not sure
input is clear enough to be The Right Way.
Same-name extends (already works in current code):
a.cfg:
[foo]
color = blue
b.cfg:
[buildout]
extends = a.cfg
[foo]
color += green
Outcome:
color = blue green
Different-name extends:
b.cfg:
[bar]
color = red
[foo]
<= bar
color += green
Outcome:
color = red green
Both extends:
a.cfg:
[foo]
color = blue
b.cfg:
[buildout]
extends = a.cfg
[bar]
color = red
[foo]
<= bar
color ++= green
Outcome:
color = blue red green
Another example:
Input as above, except:
[bar]
color = red
green
blue
[foo]
<= bar
color -+= green
Outcome:
color = red
Also, a few rants over the current implementation:
1. foo ++= bar
is the same as
foo += bar
(for any number of extra "+")
Likewise for "--="
2. foo += bar
will create a "foo +" property if [buildout] doesn't contain "extends" (ie,
wouldn't it be more consistent to always remove/strip all "+" and "-" ?)
3. foo -+=bar
will create a "foo -" property if [buildout] contains an "extends" (and if it
doesn't, see 2.). Likewise for "+-=", "+-+=", etc.
4. "foo\t+=bar" (I mean literal tab char)
will create a "foo\t" property (because rstrip is called with a parameter
which only contains space as a whitespace char)
I'm not saying those inputs make sense. I think current handling gives
surprising results, and that alone is bad IMHO.
Regards,
--
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises
More information about the Distutils-SIG
mailing list