-
Notifications
You must be signed in to change notification settings - Fork 6
Description
I briefly started looking at implementing a #4, but quickly noticed that I may have limitations if sticking strictly to the public API.
For example, given a structure like the below:
def comma_separated_str(input: str) -> list[str]:
if isinstance(input, list):
return input
return input.split(",")
@section("some_plugin")
class SomePlugin(Config):
items = key(required=False, default=[], cast=comma_separated_str)
enabled = key(required=False, default=True, cast=bool)
@section("another_plugin")
class AnotherPlugin(Config):
enabled = key(required=False, default=True, cast=bool)
@section("plugin_type1")
class MyPluginGroup(Config):
"""Grouping for analysis configuration options."""
some_plugin = group_key(SomePlugin)
another_plugin = group_key(AnotherPlugin)
class ApplicationConfig(Config):
"""Grouping for all application config items."""
plugin_type1 = group_key(MyPluginGroup)
The intent is to namespace plugins of similar type together. E.g., I could have multiple plugin types under a specific namespace, with each plugin storing its configuration in its own namespace. #2 adds the necessary hooks for dynamic addition, but I would like to be able to build a nested structure that more closely mirrors the above. For example, it should be possible to cleanly build a YAML source provider that is valid for the above ApplicationConfig
without breaking into private API.
plugin_type1:
some_plugin:
items:
- item1
- item2
another_plugin:
enabled: false
There seem to be a couple problems here - the public API only receives a section name with no context. In the above Config hierarchy, I would expect to get some notion of where I am in the section hierarchy to know where to pull a config item from. As such, I believe I would be limited to a hierarchy like this:
some_plugin:
items:
- item1
- item2
another_plugin:
enabled: false