Change Details

Better config system that does not rely on implicit configurations. # Rationale ## Current features Current configuration system is an utility library implementing diverse strategies of config loading and parsing including the following functionalities: - either absolute paths or file relative to some config directory location - brittle abstraction from config format: file extensions whitelist, but no fail otherwise - brittle abstraction from config directory location: resilient but not strict - priority loading from multiple default file paths - no clear API distinction between loading and parsing/validating - directional config merging - partial non-recursive config key type validation+conversion - both a mixin and a static class, where the config is a class attribute shared by all user code ## Wanted features - consistent config definition and processing across the SWH codebase - explicit loading - priority loading with defined mechanics ?- default configuration (global, local) - directional config merge; merge one definition with - namespaced by distinct roles, so that one fully qualified config key can be used by different units, and a same unqualified key may exist for different roles - should have a straightforward API, possibly declarative, so that user code can plug config definitions in a single step (decorator, mixin/trait, factory attribute, etc.) # Proposition ## Format and location File format: YAML? Default config: - Separate file: local or global? - Python code/Docstring Specific config: - Separate file (YAML?) ## Library swh.core.config - load/read config which assumes config can be loaded and parsed (avoid duplicating click behavior) - check that config can be loaded and parsed - priority loading : CLI switch > specific envvar > global envvar (> default path)? Either run with a switch or a envvar, else hardcoded default path ## Usage # Status WIP, feel free to contribute # Related T1758 T1388 T826 D3953 D3965 (ongoing)

Better config system that does not rely on implicit configurations. # Rationale ## Current features Current configuration system is an utility library implementing diverse strategies of config loading and parsing including the following functionalities: - either absolute paths or file relative to some config directory location - brittle abstraction from config format: file extensions whitelist, but no fail otherwise - brittle abstraction from config directory location: resilient but not strict - priority loading from multiple default file paths - no clear API distinction between loading and parsing/validating - directional config merging - partial non-recursive config key type validation+conversion - both a mixin and a static class, where the config is a class attribute shared by all user code ## Wanted features - consistent config definition and processing across the SWH codebase - explicit loading - priority loading with defined mechanics - ? default configuration (global, local) - directional config merge; merge one definition with - namespaced by distinct roles, so that one fully qualified config key can be used by different units, and a same unqualified key may exist for different roles - should have a straightforward API, possibly declarative, so that user code can plug config definitions in a single step (decorator, mixin/trait, factory attribute, etc.) # Proposition ## Format and location File format: YAML? Default config: - Separate file: local or global? - Python code/Docstring Specific config: - Separate file (YAML?) ## Library swh.core.config - load/read config which assumes config can be loaded and parsed (avoid duplicating click behavior) - check that config can be loaded and parsed - priority loading : CLI switch > specific envvar > global envvar (> default path)? Either run with a switch or a envvar, else hardcoded default path ## Usage # Status WIP, feel free to contribute # Related T1758 T1388 T826 D3953 D3965 (ongoing)

Better config system that does not rely on implicit configurations. # Rationale ## Current features Current configuration system is an utility library implementing diverse strategies of config loading and parsing including the following functionalities: - either absolute paths or file relative to some config directory location - brittle abstraction from config format: file extensions whitelist, but no fail otherwise - brittle abstraction from config directory location: resilient but not strict - priority loading from multiple default file paths - no clear API distinction between loading and parsing/validating - directional config merging - partial non-recursive config key type validation+conversion - both a mixin and a static class, where the config is a class attribute shared by all user code ## Wanted features - consistent config definition and processing across the SWH codebase - explicit loading - priority loading with defined mechanics ?-- ? default configuration (global, local) - directional config merge; merge one definition with - namespaced by distinct roles, so that one fully qualified config key can be used by different units, and a same unqualified key may exist for different roles - should have a straightforward API, possibly declarative, so that user code can plug config definitions in a single step (decorator, mixin/trait, factory attribute, etc.) # Proposition ## Format and location File format: YAML? Default config: - Separate file: local or global? - Python code/Docstring Specific config: - Separate file (YAML?) ## Library swh.core.config - load/read config which assumes config can be loaded and parsed (avoid duplicating click behavior) - check that config can be loaded and parsed - priority loading : CLI switch > specific envvar > global envvar (> default path)? Either run with a switch or a envvar, else hardcoded default path ## Usage # Status WIP, feel free to contribute # Related T1758 T1388 T826 D3953 D3965 (ongoing)