Ticket #157 (closed enhancement: wontimplement)

Opened 6 years ago

Last modified 6 years ago

YAML: Inclusion of config files with depth > 1

Reported by: bahram Owned by: tim
Priority: minor Milestone:
Component: Fawkes Version: 0.4.2
Keywords: Cc:
Git Branch:

Description

It would be nice to be able to include config files like this (which I believe should be the desired behaviour of "include"):

# /path_A/conf_a.yaml
include:
  - ../path_B/conf_b.yaml
# /path_B/conf_b.yaml
include:
  - confs/
# /path_B/confs/sub_conf.yaml
...

Loading conf_a will not include sub_conf, as the inclusion from conf_b won't consider the nested inclusion, i.e. it will try to include "/path_A/confs/".

However, conf_a should not have to make sure that conf_b gets its inclusions. In this scenario, sub_conf would not be loaded, though conf_b needs/wants it.

Change History

comment:1 Changed 6 years ago by tim

Config paths are always relative to CONFDIR unless you give an absolute path (cf. yaml.cpp). Inclusions are queued and other than the order of the file loading there is no significance of the inclusion "hierarchy". That is a particular reason why there is the meta document at the beginning for inclusions, and not in the main documentation (it would suggest namespacing of includes).

So in your example /path_A/conf_a.yaml would include CONFDIR/../path_B/conf_b.yaml, which will include any file in CONFDIR/conf.

Can you be more concrete where this is bugging you. Actually inclusion was meant to be dead simple and cover only basic cases. We should try very hard not to nest includes (too much).

comment:2 Changed 6 years ago by bahram

Can you be more concrete where this is bugging you

Yey, I added a config.yaml for the athome-branch, which of course should load all config entries from its submodule, but also allow additional config files.
So I end up with these two files (more or less):

# /../fawkes-athome/cfg/config.yaml
include:
  - ../fawkes/cfg/conf.d        #A
  - ../fawkes/cfg/config.yaml   #B
# /../fawkes-athome/fawkes/cfg/config.yaml
include:
  - conf.d/                     #C

where #B is obvious, but now #C loads

"/../fawkes-athome/cfg/conf.d/", so I need to add #A to load
"/../fawkes-athome/fawkes/cfg/conf.d".

What I actually want and what would be more straightforward would be

# /../fawkes-athome/cfg/config.yaml
include:
  - ../fawkes/cfg/config.yaml   #B'
  - conf.d/                     #A'

with #B' loading config.yaml from the main tree (and everything that's defined in there!), i.e.
with #C loading "/fawkes-athome/fawkes/cfg/conf.d/",
and #A' loading "/fawkes-athome/cfg/conf.d/".

I should not have to make sure, that the file I include (#B) gets its own includes loaded

I hope this sketch is readable :)

This might be the only case where this happens as we have a fawkes submodule (which defines the "includes" based on its own CONFDIR, but as a submodule will then fail when the config is loaded from the "master-module" which has another CONFDIR).

comment:3 Changed 6 years ago by tim

Ok, first to be clear: there is always only one CONFDIR. In the sub-module case it's the sub-module's cfg directory, the inner cfg dir is never referenced.

So basically you ask to give up on the strategy to make paths always relative to CONFDIR or absolute, and instead make includes relative to the base path of the including file or absolute.

Actually I'm not all against it, it makes sense and has been used elsewhere. I'm more concerned about the case when using this to combine a sub-module's and the core repo's config files, a few problems may arise:

  • looking for a config file now requires to look at two places, and in a specific order
  • values that are changed in the core config file will be taken into the sub-module if not explicitly overwritten.
  • It is not possible (and should not be), to erase config values. Take the laser config as an example, it configures several lasers for demonstration, though they are inactive, they may still confuse. This also means that you potentially see a lot more configuration values with ffconfig that useful or required.

So I would think that the safe bet is to copy the configuration files and have a separate set in the domain repository. If values are added in the core repository it is easy to spot, the plugin won't load anymore. That's much less of a problem.

So, I vote for copying the config once, and afterwards not using the core configuration in the domain repository anymore. Then, it still might make sense to make the change you requested, but much less so I would say. Do you agree (to both questions)?

comment:4 Changed 6 years ago by tim

Bahram, I guess we're good here and go with a single config directory not including the base config and see if we run into trouble and change it if necessary. Or am I missing something?

comment:5 Changed 6 years ago by bahram

No, you're absolutely right. As long as we don't experience any major downsides, this ticket can remain close.

comment:6 Changed 6 years ago by bahram

  • Status changed from new to closed
  • Resolution set to wontimplement
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Subscriber, Participant

  • Bahram Maleki-Fard(Reporter, Participant)
  • Fawkes Trac List(Always)
  • Tim Niemueller(Owner, Participant)