Skip to content

Extend ConfigSource to include full section namespace hierachy #5

@rpocase

Description

@rpocase

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions