You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Structuring complex configuration without repeating yourself.
In detail, the functionality should bring new query language for loading and managing the configuration.
This would definitely help to maintain a neat and tidy, yet complex configuration system.
However, if we want to maintain multiple configuration files that should actually do something similar to 'transcluding' this configuration internally, we need to either have identical copies of the common configuration in them (and then if one changes, the other may be inconsistent with it), or have something that performs the transclusion from path/to/i18n.yaml in those configuration files. That transclusion would happen without changing the documents, since the configzen library is built on abstraction over file formats – thus, in a YAML configuration we could then even import a JSON config.
Assuming that both for production and development mode of an example considered application we use the following code to load configuration:
classMyConfig(ConfigModel):
i18n: MyI18n# other independent config variables...config=MyConfig.load("path/to/development.yaml"if__debug__else"path/to/production.yaml")
then instead of maintaing separately i18n section in file
# path/to/development.yamli18n: # as in path/to/i18n.yamllocale: pl_PLtimezone: Europe/Warsaw# other independent config variables...
and separately maintaing i18n section in file
# path/to/production.yamli18n: # as in path/to/i18n.yamllocale: pl_PLtimezone: Europe/Warsaw# other independent config variables...
and wasting time on worrying whether they are the same as they should,
we could have
# path/to/development.yamli18n:
.import: path/to/i18n.yaml# other independent config variables...
and
# path/to/production.yamli18n:
.import: path/to/i18n.yaml# other independent config variables...
Please note that I could rewrite these examples into JSON, TOML or anything else supported by anyconfig and it would still work identically.
These import() statements could be even part of a rich query language, that could merge imported configurations, such as
Moreover, accessing particular scopes of the imported configurations would be considered useful.
We could make a default-settings.yaml with default configs dedicated for other models.
And this way, we would create inheritance of configurations:
# path/to/production.yaml.import: path/to/default-settings.yaml # base configurationdatabase:
# inform that we inherit from path/to/default-settings.yaml database section, # because now we just overwrite that imported section and YAML will # otherwise forget about it (it does not merge).import(database): .# overwrite desired option with our custom valuename: postgres_dev
Describe the use case of a new functionality
Structuring complex configuration without repeating yourself.
In detail, the functionality should bring new query language for loading and managing the configuration.
This would definitely help to maintain a neat and tidy, yet complex configuration system.
Example Use
Having
we could configure it with a single file
and then load it with
However, if we want to maintain multiple configuration files that should actually do something similar to 'transcluding' this configuration internally, we need to either have identical copies of the common configuration in them (and then if one changes, the other may be inconsistent with it), or have something that performs the transclusion from
path/to/i18n.yaml
in those configuration files. That transclusion would happen without changing the documents, since the configzen library is built on abstraction over file formats – thus, in a YAML configuration we could then even import a JSON config.Assuming that both for production and development mode of an example considered application we use the following code to load configuration:
then instead of maintaing separately
i18n
section in fileand separately maintaing
i18n
section in fileand wasting time on worrying whether they are the same as they should,
we could have
and
Please note that I could rewrite these examples into JSON, TOML or anything else supported by anyconfig and it would still work identically.
These
import()
statements could be even part of a rich query language, that could merge imported configurations, such asto merge dictionaries out of imported
base.yaml
andoverrides.yaml
.Namely, that would result in
Moreover, accessing particular scopes of the imported configurations would be considered useful.
We could make a
default-settings.yaml
with default configs dedicated for other models.and then, in the application development configuration:
and in the application production configuration:
And this way, we would create inheritance of configurations:
which would be equivalent to:
that eventually evaluates to
Additional context
No response
The text was updated successfully, but these errors were encountered: