Switch from argparse to Hydra

[busycalibrating]

Hi there, I first just wanted to say that this is a great project with lots of awesome implementations :slightly_smiling_face:

This is more of a proposal/feeler to see if the owners of this repo would have any interest in this, but would there be any potential interest in switching from argparse to hydra as it would add a lot of nice quality of life features? I don't really expect the owners to implement this, but depending on how much I end up playing around with this library I might end up switching to hydra for the components that I will be using anyways, and if there was interest it could be worth it to implement it for the whole library (depending on how much work it entails and how much time I have). I understand if this is not something you are interested in as well, so no worries if you'd rather not bother.

Thanks again!

[vturrisi]

Hey @busycalibrating. Thanks for your comments about solo! Actually, me and @DonkeyShot21 discussed/have been discussing about this for some time already but we couldn't decide on hydra or the other libraries available (and we also didn't have the time to properly migrate). Any reasons on why hydra is better than the other options available? If you end up using it, would you mind sharing the implementation so that we can have an idea of what extending it to the whole library would look like? We would be happy to integrate hydra if it looks good :)

[busycalibrating]

To be perfectly honesty I don't have really any experience (nor am I really aware) of any Hydra alternatives - to me it makes the most sense because its well supported (facebook) and has lots of nice quality of life features like like submitting jobs to a slurm cluster via submitit, loading defaults from config files and overriding from the command line, etc. Did you have any thoughts for any alternatives to Hydra?

But it's awesome that you are open to it! If I get around to swapping over to Hydra I'll share the implementation here and we can hopefully get it merged in! :slightly_smiling_face: I'll let you know if I run into any pain points in the meantime.

[vturrisi]

I think there's some google library (fire or something like this) and another called dynaconf. About hydra being able to submit via slurm, we need to make sure it is compatible with pytorch lightning. Anyway, I'm not particularly against hydra for any reason, it's really just a matter that I never used it.

Let me know when you have some code :)

[vturrisi]

@busycalibrating I'm closing the issue, but let us know if you make any progress.

[busycalibrating]

Sounds good - there were a few things that I ran into that I wanted to try to understand better before putting forth any proposal/implementation. Specifically, defining a schema for different models/datasets (with different defaults) follows a different pattern than what seems natural to me (e.g. structured configs) - I want to make sure I understand all of the details so that I can implement it in an optimal way.

I'll add that I do have some experience with Fire and while it was nice, I think its intended use-case is for simpler applications and to give you a quick out of the box CLI. Hydra is better suited for ML applications because its supports running multiple jobs with single commands (eg hyperparameter sweeps), (optional) integration with submitit/job schedulers, and the way it supports config files is quite nice. I don't have any experience with dynaconf however.