More ideas about re-designing config files

[vila]

>>>>> Martin Pool <mbp at canonical.com> writes:

    > Thanks for publishing that.  I think we are on the same track.
    > I think we can get there gradually though, and if we file some bugs
    > tagged say 'config' we can get there gradually.

I didn't found a shorter path than:

* implement the proposed design (in a most minimal way but still)

* begin using it (whether or not it can co-exist with the actual one is
  unclear, roughly ok if we start switching bazaar.conf at once)

* provide a transition path for the existing config files ([ALIASES]
  sections, etc). This may require adding a '__version__' option
  somewhere (probably in the default section) for better compatibility
  handling.

    > For instance we can have one step which is just to provide (and
    > document) a better internal API for looking up configuration values
    > rather than creating a GlobalConfig directly; then move code to use
    > that.  I'd like to do that early on.

    > I'm not sure just what the 'Config object' in your doc is.

That was a careful omission to avoid the name clash with the existing
Config object :)

    > (That name is probably too generic.)  Is that the same as the
    > Stack in your mail?

Yes.

    > I think the second name (or maybe ConfigStack) is more specific.

Sure, config.Stack ftw :D

But really, the ConfigRegistry should act as a factory there, so a
config, as far as bzrlib is concerned, is what ConfigRegistry gives you
back. This doesn't exclude defining config registries or option
registries for plugins.

While the option name space proposed allows many plugins to just use the
same config files than bzr itself, bialix (at least) mentioned that qbzr
want a config file for its windows, there may be little point forcing
him to use a 'qbzr.window' prefix for all the related options if he
doesn't want to.

    > I thought about this the other day because I wanted a way to configure
    > automatic lock breaking; ideally in a way such that you can control it
    > by location.  How should this look?

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

As for the config option itself, probably something like:

   config.Option('bzr.lock.break', as=Choice)

'Choice' being one of: 'True', 'False', 'Ask'.

so you can just say:

   wt.config.get('bzr.lock.break')

Now, if you really want the global config and no location:

   config.global.get('bzr.lock.break')

should do.

       Vincent

P.S.: I realize the above is still pretty handwaving some nasty dark
areas like: how do you ensure a Store is accessed only once when used by
different stacks (may be the ConfigRegistry should enforce that...)