Skip to content

Review and refactor hydra configs

  1. Review the architecture of hydra configs. One example is how defaults are handled, specifically for loggers and callbacks. For ex: replace many_loggers by default.
  2. Make the hydra configs folder available as ressources module. How to handle user defined config, that inherits from the module configs (currently equivalent to experiment configs) ? https://hydra.cc/docs/patterns/configuring_experiments/
  3. (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 customexperiment.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