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
# Implementation
# Status
WIP, feel free to contribute
# Related
T1758
T1388
T826
D3953 (ongoing)
D3965 (ongoing)