ConfigurationLoader(_run_mode: maze.api.utils.RunMode, _kwargs: Dict[str, Any], _overrides: Dict[str, Union[str, Mapping[str, Any], Any]], _ephemeral_init_kwargs: Dict[str, str])¶
A ConfigurationLoader loads and post-processes a particular configuration for RunContext. This includes injecting instantiated objects, resolving proxy arguments etc.
Returns loaded DictConfigs. :return: Loaded DictConfigs.
load() → None¶
Loads Hydra configuration and post-processes it according to specified RunContext.
This also detects inconsistencies in the specification and raises errors to prevent errors at run time. There are the following sources for such inconsistencies:
Codependent components. Some components, e.g. environments and algorithms, are completely independent from each other - each environment can be run with each algorithm. Others have a codependency with each other, e.g. Runner to Trainer: A runner is specific to a particular trainer. If a component and another component to it are specified, these have to be consistent with each other. E.g.: Running A2CMultistepTrainer and ESTrainingRunner will fail.
Derived config groups. Some config groups depend on other attributes or qualifiers, e.g. algorithm_configuration (qualifiers: algorithm, configuration) or algorithm_runner (algorithm, runner). Hydra loads these automatically w.r.t. the set qualifiers. This is not the case when RunContext injects instantiated objects though, since the value for the underlying Hyra configuration group is not changed automatically. E.g.: If an A2CAlgorithmConfig is passed, the expected behaviour would be to load the corresponding A2C trainer config in algorithm_config. Since the default value for the config group “algorithm” is “ES” however, Hydra will load the configuration for the module es-dev or es-local. This results in combining an ES trainer with a A2CAlgorithmConfig, which will fail.
Nested elements. If a super- and at least one sub-component are specified as instantiated components or DictConfigs, RunContext attempts to inject them in the loaded configuration w.r.t. to the respective hierarchy levels. This entails that more specialized attributes will overwrite more general ones. E.g.: If “model” and “policy” are specified, the model is injected first, then the policy. That way the “model” object will overwrite the loaded model and the “policy” object will overwrite the policy in the “model” object. This doesn’t occur in the CLI, since no non-primitive value can be passed.
Furthermore, it resolves proxy arguments w.r.t. the current run mode: Non-top level attributes exposed in
Returns working directories. :return: Working directories.