Is there any specific reason why

.get

method of the config loader behaves differently between

ConfigLoader

and

OmegaConfigLoader

?

cl = ConfigLoader("conf")
cl.get("custom*")
{'test': ':)'}

cl = OmegaConfigLoader("conf")
cl.get("custom*")
None

so we need to do a better job of this

In

OmegaConfigLoader

we put an explicit check:

if key not in self.config_patterns:
            raise KeyError(
                f"No config patterns were found for '{key}' in your config loader"
            )

IMO the

ConfigLoader

has a lot of loose parts where we never fully check things making some behaviour very hard to debug.

What do you suggest for the general usage in plugins? So far, we’re relied on the config loader from context (which can be user-settable) https://github.com/getindata/kedro-azureml/blob/482c943a65345dbd1dfdb749717866f094e19467/kedro_azureml/utils.py#L32

hmmm.. So if I understand correctly the user would set the config loader like usual in

settings.py

? Because then that’s where they’re able to supply additional patterns. I get this isn’t as smooth a journey as before.

Yes, user sets the config loader as desired in the project, the plugin just uses what’s provided - we think that’s a good approach, but now when custom patterns need to be specified upfront in the project, the UX of the plugins drops…

It’s a clearer separation about what’s Kedro configuration and what’s extra/external. But yes the UX for plugins is less smooth now.. 😕

It’s weird, because

AbstractConfigLoader

only has

conf_source

AbstractConfigLoader

is a whole other story.. it really isn’t designed well. It’s not possible to create a functioning config loader if you just subclass that.

this is fine