Review and refactor hydra configs
- Review the architecture of hydra configs. One example is how defaults are handled, specifically for loggers and callbacks. For ex: replace
many_loggers
bydefault
. - Make the hydra configs folder available as ressources module. How to handle user defined config, that inherits from the module
configs
(currently equivalent toexperiment
configs) ? https://hydra.cc/docs/patterns/configuring_experiments/ - (optionnal) Enhance user experience by providing him an experiment config (pulled from
configs_module/experiment/experiment_template.yaml
). Simlar to cookie cutter, we can ask question to the user to fill an experiment.yaml from the template. We can create a cookie cutter template, with just litDet as dep, and a folder for custom experiment.
Currently the configurations are available in a separate folder at the root of the repository ./configs
.
We can think of them as default configs that serve our pipelines, hence they should be available as package immutable resources (using importlib.resources
as we did with fixtures in !3 (merged)). Especially because how hydra treats them (inheritance, defaults management etc..), they could be seen as actual code, a sort of declarative language.
This has the following advantages:
- Hide the internal configurations from users, since that would be risky to change them. They should still be able to make their own custom
experiment.yaml
file and configure everything there. - Make the package installation easier with the resources living in the library (as a "module").
- Don't rely anymore on
rootutils
because config implicitely are discoverable as a module.
Edited by Loic Tetrel