Hydra: A framework that simplifies development of complex applications
engineering.fb.com
engineering.fb.com
Edit: it surprises me every time that a project like this always goes for a single language implementation. There are plenty of good concepts in there. I know purists will say “it does too much”. But when one can crank out a complex cli app and spend half time on it thanks to things like this, I’m all up for it.
1. Let's build a framework for model based RL, we can start by implementing the PETS paper (https://arxiv.org/abs/1805.12114)
2. It sure does have a lot of degrees of flexibility, and the PETS reference implementation is full of hard coded configuration. It would be nice to be able to combine configuration files somehow and override them from the command line.
3. Looking around, I didn't find anything that was quiet what I was after so I created OmegaConf (https://github.com/omry/omegaconf)
4. Building the framework, I evolved my understanding of what composing configuration actually means, and added additional features as I needed them.
5. The MBRL framework became really nice and useful, but was still primarily an implementation of PETS. I tried to make it a bit more generic to allow others in my team to use it for other things, and realized the better thing to do is to go for something totally generic and make it a standalone package, Thus Hydra was born.
It evolved into what you see today, and it was almost exclusively my work - so at no point did I have the cycles to really support development in other languages.
One of the challenges is to convince people that it's useful, It can do many things as some people point out and people can get uneasy because of that. For Hydra to succeed, people should be using it, there is no point in spending years building something no one would use. ML, which is where Hydra grew from is dominated by Python today, That's why Python is the first implementation.
Building Hydra in another language is possible, especially now that there is a reference implementation, but it's a lot of work. If you are interested in trying it out I would be happy to discuss and advise.
It does too much. Configuration? Running apps remotely? This is a big cluster of miscellaneous helper tools glued into a ball called a library. I don’t understand how it’s useful.
I do. Is that surprising, though? Given the variety of tools/frameworks to build interactive web stuff, there isn't a single thing React offers that cannot be found elsewhere.
python my_app.py db.driver=mysql db.user=omry
python my_app.py --db-driver=mysql
Philosophically speaking, I am not seeing a big advantage for Hydra overrides syntax to line up with getopt. What it does is different. For example, unlike with getopt - you MUST specify a value with every override, there is no support for flags like --verbose. it would have to be verbose=true, the reason is that those are editing the configuration object, and in 99% of the cases you want to put in a value and not default to true.
Also, you should be thinking of those command line arguments as editing a complex object. db.driver=mysql means: in the db map, change value of the driver key to mysql.
Hydra actually comes with built in Python logging configuration, it's just a part of the configuration object and Hydra is setting it up for the app: https://cli.dev/docs/tutorial/logging
You can override this from the command line (unlikely but could be useful), or completely replace it with your own logging config: https://cli.dev/docs/configure_hydra/logging
This kind of flexibility is a core part of how Hydra build the config, it's not limited to it's internal config (like logging) but extends naturally to the user config as well.
Hydra has some overlap with what MLFlow is already doing, but I am sure MLFlow can benefit from configuration composition.
Another way to look at it is: What kind of Hydra plugins can be backed by MLFlow. for example, remote launching to any cloud can be implemented as a Hydra Launcher plugin. Currently the included launcher plugin is trivial (local execution), and the more interesting launchers to launch remotely are not open sourced as hey rely on internal FB infrastructure. Supporting the major cloud providers in Hydra through plugins is definitely something I would like to see.
At the moment it's not as rich as all of the other command line libraries in term of types, enums etc but it's richer what it you can easily express with it.
For example, I challenge you do express logging configuration with oslo.config, or Click, org argparse. You would be writing a whole lot of code to come up with something very rigid. With Hydra composing hierarchical configs is trivial so logging configuration is not harder than anything else.
What you would do with those other CLI libraries is just is either either hard code your logging config (eew) or separate it into a different config file and add logic to deal with it. In my book this logic is an example of boilerplate that Hydra can handle cleanly.
Technically you can do CoProduct (ConfigA | ConfigB) (not inheritance) but the logic of unraveling such a type is too much for configs so it's very unlikely Hydra does this.
(Assuming I understand your exact meaning).