More ideas about re-designing config files

[Martin Pool]

On 31 March 2011 18:02, vila <v.ladeuil+lp at free.fr> wrote:
>    > In pseudocode, it's
>
>    >   get_config_stack(url=lockdir_url).get_option_as_boolean('bzr.auto_break_dead_locks')
>
>    > is that enough?
>
>        config.regsitry.get('bazaar', location).get('bzr.auto_break_dead_lock', as=bool)
>
> is roughly the target.
>
> Except that Global(location) is probably wrong. While 'bazaar.conf' (the
> Store) can provide default values for various contexts, these contexts
> are probably *also* getting options from different stores.
>
> There is certainly an already known object that could provide the
> location, let say the working tree:
>
>        wt.config.get('bzr.auto_break_dead_lock', as=bool)
>
> knowing that at lock time (hu ho, breaking lock here remember, you
> really had to start with such a nasty example... ;) the working tree can
> provide the location itself to build a config stack as:
>
> * command-line options
> * os.environ
> * a stack for matching sections in locations.conf
> * a stack for matching sections in tree.conf
> * a stack for matching sections in bazaar.conf
>
> So basically the new design provides the configs applying to a given
> context when the objects themselves are built (working trees, branches,
> repos, etc).

Having a config stack available on key objects (branch, etc) that
looks up the right configuration for that object sounds good; it
should also give the right cache life time.  We'll have to make sure
that just building the stack does not eagerly load all the config
files because it's probably quite possible to use an object without
needing its config.

If we create the config stack when the object is created we can put in
just one place the policy about which files are consulted.

Let's call it .config_stack, to make it clear that branch.config_stack
is everything that applies to the branch, not just the branch.conf.
That would be a good thing to put in the developer guide that we have
this pattern.

Some objects like LockDir will want to be configurable but don't
really have an opinion about where their configuration should be
stored.  Perhaps when eg the Branch constructs one it can tell the
lockdir where to gets its configuration.  Perhaps following that
pattern of passing things down into lower-level objects will be enough
to avoid ever needing actual globals for it.

It seems like we should then also be able to do away with eg
BranchConfig and just have it be an instance of a Store that's
addressing a particular file.

Using the registry of options to set the default type interpretation
would be good.

The registry of options needs to be done with care for lazy loading.