flexmeasures
flexmeasures copied to clipboard
Improve checks for FlexMeasures' own config settings based on checks for plugin config settings
From discussion in https://github.com/SeitaBV/flexmeasures/pull/230.
Foremost, we want to improve how we encode config settings requirements and replace config_utils.are_required_settings_complete
and config_utils.get_config_warnings
with functionality we use to check config settings registered by plugins. This means we'll then be able to more expressively define our expected config settings.
Secondly, configs are growing up within FlexMeasures, so we may want to refactor to give configs their own config
sub-package.
@nhoening suggested the following files for the config
sub-package:
-
__init__.py
-
Readme.md
-
utils.py
-
defaults.py
-
requirements.py
The latter would be where we put the requirements we talk about here. I call it requirements, as I don't think we should list all possible settings there. Or what do you think we should do?
Given that our settings specification now looks like the example below, I'd prefer to keep all config settings together, and not just the required ones. I can also imagine it makes sense to just extend the specification with a "default"
key.
settings = [
"MY_PLUGIN_URL": {
"description": "URL used by my plugin for x.",
"level": "error",
},
"MY_PLUGIN_TOKEN": {
"description": "Token used by my plugin for y.",
"level": "warning",
"message_if_missing": "Without this token, my plugin will not do y.",
"parse_as": str,
},
"MY_PLUGIN_COLOR": {
"description": "Color used to override the default plugin color.",
"level": "info",
},
]
I thought about this avenue for a bit, but it changes the way we load settings in a larger way.
There are many settings FlexMeasures relies on, many even defined in other packages. I'm not sure where the line would be to decide which ones need to be mentioned, if only for a default, while others do not.
What about "just" the ones we mention in https://flexmeasures.readthedocs.io/en/latest/configuration.html?
Those are all we list in the config_default module I believe. I counted 53.
I counted ten among them which are required (e.g. databases) or recommended (e.g. mail). So that is the lower boundary.