7
As a Bazaar developer there are a few things you need to know about
10
* how to add a new option,
12
* how add a new stack,
14
* how add a new store.
16
The first sections in this document summarize the steps needed when adding a
17
new configuration item, the rest of the document gives more internal details
18
on how this is implemented.
23
Options values are obtained with ``stack.get(option_name)`` where ``stack``
24
is one of the daughter classes of ``config.Stack``, see their docstrings for
25
a description of which sections are used from which stores.
27
The value returned is of the type declared for that ``Option`` and if
28
nothing is specifically declared you will get the default for that option.
33
You add a new ``Option`` to the ``option_registry``, either inside
34
``bzrlib/config.py`` or during initialization of your plugin (use
35
``register_lazy`` in this case). New plugins should have systematic
36
hierarchical names so that related values are grouped together::
38
option_registry.register(
39
Option('dirstate.fdatasync', default=True,
40
from_unicode=bool_from_store,
41
help="Flush dirstate changes onto physical disk? ...."))
43
You then need to decide which stack is appropriate to implement the Option
46
* which config files (aka ``Store``) needs to be queried, which sections are
47
relevant and in what order,
49
* which section will receive the modifications (if relevant).
51
The docstrings for the existing stacks cover most of the known use cases.
53
Modify an option value or delete an option
54
------------------------------------------
56
Just reading an option is what is needed most of the time, modifying option
57
values or removing options is usually something that is not automated but
58
left to the user (with ``bzr config``).
60
Nevertheless, if you need to save a modified option value, use
61
``.set(option_name, value)`` and ``.remove(option_name)`` to delete the
62
option. Both methods are provided by the ``Stack`` object.
64
But before doing that, you must be sure that the stack you're using have a
65
writable section (this is true for ``GlobalStack`` which uses the
66
``DEFAULT`` section in ``bazaar.conf`` and for ``BranchStack``which uses the
67
no-name section in ``branch.conf``).
69
Old and new configuration code
70
------------------------------
72
There is (as of late 2011) some older and some newer configuration code. The
73
old code has specific methods for various checks or uses classes like
74
``GlobalConfig``. Don't add to to it; try to remove it.
76
If you encounter an option using the old code you may want to migrate
77
it. This generally involves:
79
* registering the option,
81
* replace the old config by a stack:
83
* ``GlobalConfig`` became ``GlobalStack``,
85
* ``LocationConfig`` became ``LocationStack``,
87
* ``BranchConfig`` became ``BranchStack`` (or in this case,
88
``get_config()`` became ``get_config_stack()``.
90
* replace the custom accessor calls with ``conf.get(option_name)``.
92
The new config code provides some help for commonly encountered use cases
93
that can allow further simplifications like:
95
* providing a default value when the option is not defined in any way by the
98
* convert the unicode string provided by the user into a suitable
99
representation (integer, list, etc).
104
Stacks capture the various places an option can be declared by the user with
105
associated levels of generality and query them in the appropriate order
106
returning the first definition found. For example, the
107
``append_revisions_only`` option may be declared for all branches of a user
108
in ``bazaar.conf``, or for a hierarchy of branches in ``locations.conf`` or
109
in a single branch in ``branch.conf``.
111
Defining a new stack means you need a new way to expose these levels to the
112
user that is not covered by the existing stacks.
114
This is achieved by declaring:
116
* which stores can provide a value for the option,
118
* which sections apply to the stack instance, some filtering for a given
119
context can be defined,
121
* which (store, section) should receive the modifications.
123
Mapping different sections to different stacks is a powerful way to organize
124
the options and provide various levels of configuration to the user. This is
125
achieved with ``Store`` and ``SectionMatcher`` objects.
131
The following stores are used by ``bzr`` in ways that illustrate various
137
``bzr`` itself defines two sections here:
139
* ``DEFAULT`` where global options are defined,
141
* ``ALIASES`` where command aliases are defined. This section is *not*
142
available via ``GlobalStack``, instead, the ``bzr alias`` command uses it
143
for its own purposes.
145
Plugins can define either additional options in the ``DEFAULT`` section or
146
new sections for their own needs (this is not especially encouraged
147
though). The ``bzr-bookmarks`` plugin defines a ``BOOKMARKS`` section there
153
The Ubuntu package importer defines a store and two stacks involving
154
``pkgimport.conf``. A no-name section contains the options common to all
155
packages and sections named after their corresponding package can also be
158
The ``ImporterStack`` uses ``locations.conf`` and the no-name section in
159
``pkgimport.conf`` for the importer options.
161
The ``PackageStack`` uses only ``pkgimport.conf`` and uses the section name
162
after the package followed by the no-name section.
167
``bzr`` defines sections corresponding to URLs there and includes the
168
relevant sections in ``LocationStack`` and ``BranchStack``. No no-name
169
section is recognized in this file.
174
This file defines the option for a given branch and uses only the no-name
180
The Option object is used to define its properties:
182
* name: a name: a valid python identifier (even if it's not used as an
183
identifier in python itself). This is also used to register the option.
185
* from_unicode: a callable accepting a unicode string and returning a
186
suitable value for the option. If the string cannot be coerced it should
189
* default: the default value that Stack.get() should return if no value can
190
be found for the option. This can also be a callable as long as it returns
193
* default_from_env: a list of environment variables. The first variable set
194
will provide a default value overriding 'default' which remains the
195
default value if *no* environment variable is set.
197
* help: a doc string describing the option, the first line should be a
198
summary and can be followed by a blank line and a more detailed
199
explanation. This will be displayed to the user with::
201
bzr help <option name>
203
* invalid: the action to be taken when an invalid value is encountered in a
204
store (during a Stack.get()).
206
The value of an option is a unicode string or ``None`` if it's not
207
defined. By using ``from_unicode`` you can turn this string into a more
208
appropriate representation.
210
If you need a list value, you should use ``ListOption`` instead.
216
Options are grouped into sections which share some properties with the well
219
* the key is the name,
220
* you can get, set and remove an option,
221
* the value is a unicode string.
223
MutableSection is needed to set or remove an option, ReadOnlySection should
230
Options can be persistent in which case they are saved into Stores.
232
``config.Store`` defines the abstract interface that all stores should
235
This object doesn't provide direct access to the options, it only provides
236
access to Sections. This is deliberate to ensure that sections can be
237
properly shared by reusing the same underlying objects. Accessing options
238
should be done via the ``Section`` objects.
240
A ``Store`` can contain one or more sections, each section is uniquely
241
identified by a unicode string.
243
``config.IniFileStore`` is an implementation that use ``ConfigObj``.
245
Depending on the object it is associated with (or not) a ``Store`` also needs
246
to implement a locking mechanism. ``LockableIniFileStore`` implements such a
247
mechanism for ``IniFileStore`` based stores.
249
Classes are provided for the usual Bazaar configuration files and could be
250
used as examples to define new ones if needed. The associated tests provides a
251
basis for new classes which only need to register themselves in the right
252
places to inherit from the existing basic tests and add their own specific
255
A ``Store`` defines how option values are stored, this includes:
257
* defining the sections where the options are grouped,
259
* defining how the values are quoted/unquoted for storage purposes. Stacks
260
use the unquoted values internally (default value handling and option
261
expansion are simpler this way) and ``bzr config`` quote them when they
262
need to be displayed.
268
For some contexts, only some sections from a given store will apply. The
269
``SectionMatcher`` objects are used to define which sections in a store
270
apply to a given context.
272
The main constraint here is that a ``SectionMatcher`` should delay the loading
273
of the associated store as long as possible. The constructor should collect
274
all data needed for the selection and uses it while processing the sections in
277
Only ``ReadOnlySection`` objects are manipulated here but a
278
``SectionMatcher`` can return dedicated ``Section`` objects to provide
279
additional context (the ``LocationSection`` add an ``extra_path`` attribute
280
to implement the section local options for example). If no sections match,
281
an empty list is returned.
283
Options local to a section can be defined for special purposes and be
284
handled by ``Section.get()``. One such option is ``relpath`` which is
285
defined in ``LocationSection`` as an alternative to the ``appendpath``
288
For ``appendpath``, the ``LocationSection`` will carry ``extra_path`` as the
289
relative path between the section name and the location used. ``relpath``
290
will be available as a ``Section`` local option with the same
291
value. ``basename`` will carry the location base name and be available as a
292
local option with the same name. Note that such options can only be expanded
293
inside the section that defines them.
295
Specific section matchers can be implemented by overriding ``get_sections``
300
* ``NameMatcher(store, unique_id)``: To select a single section matching
303
* ``LocationMatcher(store, location)``: To select all sections that match
304
``location`` sorted by decreasing number of path components.
306
* ``StartingPathMatcher(store, location)``: To select all sections that
307
match ``location`` in the order they appear in the ``store``.
312
An option can take different values depending on the context it is
313
used. This can involve configuration files, options from the command line,
314
default values in bzrlib and then some.
316
Such a context is implemented by creating a list of ``Section`` stacked upon
317
each other. A ``Stack`` can then be asked for an option value and returns the
318
first definition found.
320
This provides a great flexibility to decide priorities between sections when
321
the stack is defined without to worry about them in the code itself.
323
A stack also defines a mutable section (which can be None) to handle
326
Many sections (or even stores) are aimed at providing default values for an
327
option but these sections shouldn't be modified lightly as modifying an option
328
used for different contexts will indeed be seen by all these contexts.
330
Default values in configuration files are defined by users. Developers
331
shouldn't have to modify them, as such, no mechanism nor heuristics are used
332
to find which section (or sections) should be modified.
334
A ``Stack`` defines a mutable section when there is no ambiguity. If there
335
is one, then the *user* should be able to decide and in this case a new
336
``Stack`` can be created cheaply.
338
Different stacks can be created for different purposes, the existing
339
``GlobalStack``, ``LocationStack`` and ``BranchStack`` can be used as basis
340
or examples. These classes are the only ones that should be used in code,
341
``Stores`` can be used to build them but shouldn't be used otherwise, ditto
342
for sections. Again, the associated tests could and should be used against the
345
Also note that ``MemoryStack`` can be used without any disk resources which
346
allows for simpler and faster tests. A common pattern is to accept a
347
``config`` parameter related to a given feature and test it with predefined
348
configurations without involving the whole
349
stack. ``bzrlib.tests.test_commit``, ``bzrlib.tests.test_gpg`` and
350
``bzrlib.tests.test_smtp_connection`` are good examples.
added
removed
doc/developers/configuration.txt
