More ideas about re-designing config files

[vila]

>>>>> Andrew Cowie <andrew at operationaldynamics.com> writes:

    > On Wed, 2011-03-30 at 16:24 +0200, vila wrote:
    >> The main part is a new design to address the needs collected so far.

    > Wow, holy Not Invented Here, Batman!

<shudder> I tried hard holy Robin, I swear !

    > So, can you maybe say what the problem is?

I mentioned http://doc.bazaar.canonical.com/devnotes/configuration.html,
did you read it ? I summarized many limitations of the actual design
there.

    > Admittedly, Bazaar's configuration infrastructure is a bit
    > convoluted already,

Which part do you have in mind here ?

I've tried to simplify some parts for the user and some others for the
dev, I'm very keen to pursue these efforts if you can point me to the
parts that you don't like.

The new design should simplify the way we access remote configs for
example, have a look at the classes involved today and try to modify
set_option, just for fun.

It will also make it easier for the user to get his hands on some
options that are *already* implemented by bzrlib but currently unusable
from the command line.

    > but as soon as you start saying things like "these are read-only"

Right, I certainly should have explain a bit more there.

Most of the stacking stuff is about providing default values for various
contexts.

Each time I thought about modifying an option value I was faced with the
problem that, from *code*, even for a well defined context, you almost
never want to *modify* a default value. Most of the time you want to
*define* a new value for the *exact* object you're using.

So instead of providing complicated APIs to decide what was the option
definition you wanted to modify, I thought that, most of the time
(imbw), you know perfectly *where* you want to define a specific value
that will take precedence over the provided defaults: for a given
working tree, a given branch, etc.

But more importantly, all this config stuff is generally defined by the
user itself by editing the relevant config files and we want to provide
a way to not repeat yourself as much as we can hence the emphasis on
allowing options to be defined in sections that can be used to define
various kind of contexts. And that in turn means we have many different
sources[1].

At this point it seems clearer to be explicit when you build your
configuration to separate:

- where you get the value (including all applicable defaults),
- where you set the value.

    > you're talking about a rather complicated space that meanwhile
    > lots of other systems have addressed.

Well, the main issues I didn't find addressed in other systems are:

- lock handling,
- remote access,
- default values layering including user-defined sections selection,
  command-line options and environment variables.

    > So maybe:

    > a) re-engineer for much greater simplicity?

Can you elaborate on that ? I really want to provide an easier solution
than the existing one.

    > b) use something like dconf and/or GSettings for all this?

    > GSettings has a file back end in addition to the dconf one...

The proposed design should allow the use of such a back end (keeping in
mind that we want to access remote configs for both the smart server and
the dumb ones).

On the other hand, I don't want bzr to depend on gtk+ if I can avoid it.

    Vincent

[1]: jelmer, on IRC, rightfully raised the concern that *this* may
already be too complicated for users to decide *where* the default
should be specified (and how) if there are too many config files
involved. 

I think it's ok *as long* as there is a good way to look at what config
options are taken into account for a given context.

That's what 'bzr config -d <dir> --scope <config ID>' is about. 

I've stopped using 'bzr info' since 'bzr config' is available because it
gives me a better way to understand the interactions between
'locations.conf' and 'branch.conf' already.