More ideas about re-designing config files
vila
v.ladeuil+lp at free.fr
Wed Mar 30 14:24:08 UTC 2011
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
More information about the bazaar
mailing list