4
A configuration option has:
6
* a name: a valid python identifier (even if it's not used as an
7
identifier in python itself)
9
* a value: a unicode string or a list of unicode strings.
14
The Option object is used to define its properties:
16
* name: a name: a valid python identifier (even if it's not used as an
17
identifier in python itself). This is also used to register the option.
19
* default: the default value that Stack.get() should return if no
20
value can be found for the option.
22
* default_from_env: a list of environment variables. The first variable set
23
will provide a default value overriding 'default' which remains the
24
default value if *no* environment variable is set.
26
* help: a doc string describing the option, the first line should be a
27
summary and can be followed by a blank line and a more detailed
30
* from_unicode: a callable accepting a unicode string and returning a
31
suitable value for the option. If the string cannot be coerced it should
34
* invalid: the action to be taken when an invalid value is encountered in a
35
store (during a Stack.get()).
40
Options are grouped into sections which share some properties with the well
43
* the key is the name,
44
* you can get, set and remove an option,
45
* the value is a unicode string.
47
MutableSection is needed to set or remove an option, ReadOnlySection should
53
Options can be persistent in which case they are saved into Stores.
55
``config.Store`` defines the abstract interface that all stores should
58
This object doesn't provide direct access to the options, it only provides
59
access to Sections. This is deliberate to ensure that sections can be
60
properly shared by reusing the same underlying objects. Accessing options
61
should be done via the ``Section`` objects.
63
A ``Store`` can contain one or more sections, each section is uniquely
64
identified by a unicode string.
66
``config.ConfigObjStore`` is an implementation that use ``ConfigObj``.
68
Depending on the object it is associated with (or not) a ``Store`` also needs
69
to implement a locking mechanism. ``LockableConfigObjStore`` implements such a
70
mechanism for ``ConfigObj`` based stores.
72
Classes are provided for the usual Bazaar configuration files and could be
73
used as examples to define new ones if needed. The associated tests provides a
74
basis for new classes which only need to register themselves in the right
75
places to inherit from the existing basic tests and add their own specific
81
For some contexts, only some sections from a given store will apply. Defining
82
which is what the ``SectionMatcher`` are about.
84
The main constraint here is that a ``SectionMatcher`` should delay the loading
85
of the associated store as long as possible. The constructor should collect
86
all data needed for the selection and uses it while processing the sections in
89
Only ``ReadOnlySection`` objects are manipulated here but a
90
``SectionMatcher`` can return dedicated ``Section`` objects to provide
91
additional context (the ``LocationSection`` add an ``extra_path`` attribute
92
to implement the ``appendpath`` policy for example). If no sections match,
93
an empty list is returned.
95
.. FIXME: Replace the appendpath example if/when it's deprecated ;)
97
Specific section matchers can be implemented by overriding ``get_sections``
102
* ``LocationMatcher(store, location)``: To select all sections that match
105
* ``NameMatcher(store, unique_id)``: To select a single section matching
111
An option can take different values depending on the context it is used. Such
112
a context can involve configuration files, options from the command line,
113
default values in bzrlib and then some.
115
Such a context is implemented by creating a list of ``Section`` stacked upon
116
each other. A ``Stack`` can then be asked for an option value and returns the
117
first definition found.
119
This provides a great flexibility to decide priorities between sections when
120
the stack is defined without to worry about them in the code itself.
122
A stack also defines a mutable section (which can be None) to handle
125
Many sections (or even stores) are aimed at providing default values for an
126
option but these sections shouldn't be modified lightly as modifying an option
127
used for different contexts will indeed be seen by all these contexts.
129
Default values in configuration files are defined by users. Developers
130
shouldn't have to modify them, as such, no mechanism nor heuristics are used
131
to find which section (or sections) should be modified.
133
A ``Stack`` defines a mutable section when there is no ambiguity. If there
134
is one, then the *user* should be able to decide and in this case a new
135
``Stack`` can be created cheaply.
137
Different stacks can be created for different purposes, the existing
138
``GlobalStack``, ``LocationStack`` and ``BranchStack`` can be used as basis
139
or examples. These classes are the only ones that should be used in code,
140
``Stores`` can be used to build them but shouldn't be used otherwise, ditto
141
for sections. Again, the associated tests could and should be used against the
added
removed
doc/developers/configuration.txt
