More ideas about re-designing config files

[vila]

>>>>> Marius Kruger <amanic at gmail.com> writes:

    > +1
    > thanks for working on this.

My pleasure, your feedback is very much appreciated.

    > Each plugin had to implement its own config stacking
    > (branch.conf->locations.conf->bazaar),
    > the last time I looked, so this will hopefully fix that!

zomg, I hope you meant locations.conf -> branch.conf -> bazaar.conf as
this is what is currently implemented. 'locations.conf' is aimed at
*overriding* option values in 'branch.conf', not providing defaults for
'branch.conf' !

Now, if *no* values are specified in 'branch.conf', this makes no
difference of course and it's easy to believe that default values are
provided (I had, and probably spread, this belief too, until I really
dig into the code).

Allowing sections in 'bazaar.conf' *will* provide defaults for
'branch.conf' with this proposal.

    > On 1 April 2011 11:27, vila <v.ladeuil+lp at free.fr> wrote:

    >> * I want a dict for all values starting with this prefix. This is
    >>  requested by bialix for qbzr. I'm not fully convinced yet unless a lot
    >>  of constraints are added: a single level dict, all values are strings,
    >>  etc. And even there deciding if a dict can be built from options
    >>  coming from different sections (to provide default values) still
    >>  sounds complicated.

    > yeah I also need this.

    > I can understand that it is complicated. I think the values in the
    > dict should also stack so if x_a is in the branch.conf and x_b is
    > in bazaar.conf then give a dict {a:,b:}.  But is x_a is in both
    > then use the most specific one i.e the one in branch.conf.

Yeah, but I'm more worried about users than about implementation here,
this can really become far too complicated for users vs only slightly
more comfortable for devs. The debate is still open.

    > I actually need a list of values, but can live with a dict:
    > x_1
    > x_2
    > x_3

You already have lists ! And you will still get them, this is explicitly
described (though without firmly deciding on some points) in
http://doc.bazaar.canonical.com/devnotes/configuration.html

And in fact the implementation landed in revno 5684 (i.e. >= 2.4b1 [1])
provides option expansion including lists *but* limited to a single
config file (but config stacks will trivially (ok, easily ;) address
expanding lists across all involved config files).


    > but it would be nice to be able to get a concatenated or optionally a
    > non-concatenated list:
    > * concatenated - contains a list of all the values in all the
    >   config files
    > * non-concatenated - contains only the values from the most
    >   specific  config

Hmm, I'd prefer to give the control to the *user* there and I think the
url above provides a way to express both cases, so the API itself
doesn't need parameters for that (IMHO).

  bazaar.conf:
    debug_flags = hpss
  
  branch.conf for mybranch:
    debug_flags = {debug_flags}, hpssdetail
  
  $ bzr -d mybranch config debug_flags
  hpss, hpssdetail

vs

  bazaar.conf:
    debug_flags = hpss, hpssdetail
  
  branch.conf for mybranch:
    debug_flags = http, hpss
  
  $ bzr -d mybranch config debug_flags
  http, hpss


    Vincent

[1]: bzr branch lp:bzr -rbzr-2.4b1 [2]

[2]: bzr branch http://pad.lv/bzr/2.4b1 is longer ;-p