buildout: supporting += and -= in <=-style extends

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

buildout: supporting += and -= in <=-style extends

Vincent Pelletier
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
_______________________________________________
Distutils-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/distutils-sig