-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow mobanfile to include data from arbitrary config files #126
Comments
An approach which requires little introduction of new terminology or concepts is to allow A.yaml: overrides:
B.yaml:
C.yaml:
... but still support the old shorter syntax overrides: B.yaml
... For this approach, it would be very acceptable that B & C are not allowed to have the same keys, because there is no defined order in how they should be merged (which is why it is a mapping instead of an array). This could then be extended to have the mapping value select only a subset of values to be obtained from the mentioned files. e.g. A.yaml: overrides:
B.yaml: translations
C.yaml: dependencies
... And array syntax is available in the future if there is a need to have mutliple includes which contain the same keys. |
The other place where multiple yaml files could be introduces is the inner configuration:
template_dir:
- "setupmobans:templates"
- ".moban.d"
configuration:
moban.yml:
other.yaml: and targets:
- output: CHANGELOG.rst
template: CHANGELOG.rst.jj2
configuration:
changelog.yml:
mobanfile: The latter example could be used to remove the |
so a yaml file (A) can include any number of header(yaml) files and keys in A will override any in the included yaml files. Then in the list of yaml files in A's include list, keys in latter ones will override former ones. I.e.: overrides: keys in C will overrides B. |
the following syntax will introduce order
|
Currently a mobanfile can only include one
overrides:
to list a yaml file which contains more settings.In order to split input data into multiple files, the following is needed: A.yaml
overrides:
B.yamloverrides:
C.yamlHowever B and C may have unrelated set of data, so it is an annoyance that B should refer to C.
This also reduces re-usability.
Another project (Z) might want to use the values in B , but not the values in C.
A should be able to directly include B and C, while Z includes B only.
The text was updated successfully, but these errors were encountered: