I have revisited configuration part and this PR is result of my analysis:
karton.config.Config is pretty useless abstraction on ConfigParser and amount of self.config.config proves it. I replaced it with regular ConfigParser loader which should be single source of truth for Karton service configuration. Internally it uses regular dict which may contain both typed values or strings from ConfigParser.
Because ConfigParser is main configuration object, configuration overrides provided via CLI arguments should be mapped to the ConfigParser. That's why I introduced options and KartonBase.options_from_argsKartonBase.config_from_args that represent arguments in a format that can be mapped into config dictionary.
In the same time found some bugs in handling of existing configuration, especially in karton-system.
This PR breaks compatibility so version is bumped to v5.0.0. It shouldn't be a huge issue for most services, because Config override was pretty rare in Karton consumers.
Ok, decided to leave Config object but configuration is kept in regular dict instead of ConfigParser instance. I also added some ConfigParser-like methods to get values using the same interface as in ConfigParser.
This PR addresses #121 and unlocks #124.
I have revisited configuration part and this PR is result of my analysis:
karton.config.Config
is pretty useless abstraction on ConfigParser and amount ofself.config.config
proves it.I replaced it with regular ConfigParser loader which should be single source of truth for Karton service configuration.Internally it uses regular dict which may contain both typed values or strings from ConfigParser.options
andKartonBase.options_from_args
KartonBase.config_from_args
that represent arguments in a format that can be mapped into config dictionary.This PR breaks compatibility so version is bumped to v5.0.0. It shouldn't be a huge issue for most services, because Config override was pretty rare in Karton consumers.
I think it still needs to be redesignedCloses #121