More ideas about re-designing config files

[vila]

I've pushed an updated version of configuration.txt on
lp:~bzr-core/bzr/devnotes that should soon be available at
http://doc.bazaar.canonical.com/devnotes/configuration.html

The main part is a new design to address the needs collected so far.

Roughly, a section is a dict of options. Most of the time we want to
work with a stack of sections to be able to define default values that
apply to various contexts.

Most of the time (>95%) we need only a read-only access to the option
values and part of the complexity of the actual model is modifying *one*
option value.

So this design addresses these issues by saying: a config is a stack of
read-only section *and* *one* mutable section.

Sections are read and written from Stores which abstract the
implementation (the main one will still be ConfigObj).

Since I can't find a way to introduce these new concepts incrementally
(even the limited expand_options stuff has been hard to land), I'd like
feedback on this design before going to far in the implementation.

Option
~~~~~~
* name
* help
* default value (optional)
* list of allowed Config IDs (this allows a list of possible
  config files in bazaar.conf only option and use it while
  bootstrapping the config creations)
* blacklist of config IDs (some options *can't* be stored (modified) by the
  user)

OptionRegistry
~~~~~~~~~~~~~~
* ensures that an option ID is a unique name

Section
~~~~~~~
* section ID (for a given Store)
* dict of (name, value) pairs defining options

* dict of (name, original_value) pairs used to detect conflicting
  modifications

Stack
~~~~~
* A list of read-only Section/Stack objects

* A single mutable Section object and its associated Store (defined only if
  the stack support modification)

* a lazy cache for the option values (should be reset on modifications as
  interpolations will make it tricky to update incrementally).

* ensures that the Stores involved generate as less IOs as possible

* ensures that the transaction is the object life time (i.e. modifications
  will be taken into account *iff* they are committed explicitly).

ConfigRegistry
~~~~~~~~~~~~~~

* ensures that a config ID is a unique identifier
* register Stacks

Store
~~~~~

* url
* config ID
* can serialize/deserialize a dict of Sections
* can cache reads and writes
* ensures that the transaction is the object life time (i.e. modifications
  will be taken into account *iff* they are committed explicitly).
* can be read-only or read/write at build time
* can provide an ordered list of Section for a given context

Examples
--------

section examples
~~~~~~~~~~~~~~~~

* os.environ
* options provided on the command-line
* actual branch.conf
* any section in a Store
* a dict for section or store specific options ('relpath', 'nick', etc)

store examples:
~~~~~~~~~~~~~~~

* ConfigObj (bazaar.conf)

* DB (<scheme>://bazaar.launchpad.net/bazaar.conf)

stack examples
~~~~~~~~~~~~~~

The actual GlobalConfig will become a stack with:
* options from the command-line
* os.environ
* the default section from bazaar.conf

The actual BranchConfig will become a stack with:
* options from the command-line
* os.environ
* a stack for the matching sections in locations.conf
* a stack for the matching sections in branch.conf
* a stack for the matching sections in bazaar.conf

The modifications will be made to the section in branch.conf specified when
building the branch config object (generally the default section).


This hopefully makes sense if you've read the url above ;)

     Vincent