Config sections don't cascade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EnDroid |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
When a plugin (bar) requests its config in a given context (room: foo), it should be returned the aggregate of the config from the following sections, in priority order (i.e. a given config item in an earlier section overrides the same config item in any later section):
plugin : bar : room : foo
room : foo : plugin : bar
plugin : bar : room : *
room : * : plugin : bar
plugin : bar
plugin : * : room : foo
room : foo : plugin : *
plugin : *
Similarly, if the core needs any configuration within a given context (room: foo), it should similarly use the following precedence:
room : foo
room : *
Setup
(this latter applies to, e.g. the "plugins" configuration item)
This should all be abstracted by the configparser module.
Changed in endroid: | |
importance: | Medium → Wishlist |
The configparser module does this to some extent, with the config:
[foo:bar]
var = 0
[foo|far:bar]
var = 2
[*:bar|baz]
var=7
[foo:*]
var = 4
[foo|far:*]
var=5
[foo:bar|baz]
var = 1
[*:bar]
var = 6
[foo|far:bar|baz]
var = 3
[*:*]
var=8
parser.get("foo", "bar", "var", return_all=True)
returns [0,1,2,3,4,5,6,7]
Some sections in usermanagement's read_config file could be changed from:
config = conf.get("room", name, key), which returns only the most relevant result
to something like
def combine(dct, new):
dct.update(new)
return dct
config = reduce(combine, reversed( conf.get( ..., return_all=True)), {})
Which would combine results from all possibly relevant sections of the config file.
Alternatively there could be an extra kwarg in get that would do this.