More ideas about re-designing config files

[Marius Kruger]

On 2 April 2011 11:34, vila <v.ladeuil+lp at free.fr> wrote:
>>>>>> Marius Kruger <amanic at gmail.com> writes:
> 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).

I didn't know that thanks, but never had stuff configured in both
places that I can remember.

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

great

>    > 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.

It does not sound too complicated for users to me, it is just config options.
I don't think if some are prefixed with something that  will complicate things
You need to get it exactly right so you would probably copy&paste it
from somewhere.

> 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).

cool.

>    > 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).

That's even better. +1

>  bazaar.conf:
>    debug_flags = hpss
>
>  branch.conf for mybranch:
>    debug_flags = {debug_flags}, hpssdetail

I assume that if {debug_flags} was not defined higher up the stack
then it will not complain that there is nothing in front of the comma.
With the old Config if the option did not have a comma you just got a
string then you have to check manually weather it is a list or not.
So with the new stuff you can hopefully ask for a stringlist and you
will always get a list.

Is the plan to get rid of the separate rules config as well? Then we
can finally have branch-specific rules.
(Although sometimes you may want the rules to propagate on push like
tags, and sometimes not.
But that is another story)

-- 
<>< Marius ><>