Pytorch-lightning: Add argparse + hydra tutorial to the docs

[yukw777]

I tried mixing argparse with hydra: https://github.com/yukw777/leela-zero-pytorch/blob/983d9568ed34ed06ebde47ecb65b1e3b2d3a37c0/leela_zero_pytorch/train.py#L17-L52

This way Hydra doesn't own the logging directory structure.

awesome this is great! mind adding a tutorial to the docs on this? (under hyperparameters)

_Originally posted by @williamFalcon in https://github.com/PyTorchLightning/pytorch-lightning/issues/807#issuecomment-647770135_

[yukw777]

it seems like I don't have permission to assign this to me, so please assign this to me whenever you get a chance!

[Borda]

@yukw777 neither we can do an arbitrary assignment, they have to comment on an issue so we can assign them the task afterwards :rabbit:
cc: @Ceceu @omry

[omry]

Hi Peter.
Please be aware that by using the compose API as an alternative to hydra.main() you are forfeiting some important features of Hydra. Here is a partial list:

1. Command line integration
2. Tab completion
3. Help integration (--help).
4. Multirun support (Built in basic sweeper, as well as new Hyper parameter optimization plugins like the Ax and Nevergrad sweepers in Hydra 1.0)
5. Launchers support, currently including Joblib for local parallel execution, Submitit for SLURM launching, and RQ (from today) for Redit queue launching.
   There is an upoming Ray Launcher that will support launching directly to AWS.
6. Automatic logging configuration
7. Automatic working directory management

The compose API is designed for scenarios where you do not have a command line available, for example Jupytrer notebooks and unit tests.

I am actively discouraging people from using it in an argparse interface because because it gives up so much of the functionality of Hydra.
You are of course free to use it, but I do not think this is a good example of Hydra usage.

I am working with @anthonytec2 on an integration that benefits more from what Hydra 1.0.0rc1 can offer.

You can check it here (This is work in progress).

[yukw777]

amazing @omry! that should definitely be the way to go. one of the biggest reasons i went with the python api route is that hydra manages the output directory structure so it was messy when i used it with pytorch lightning as it also manages its own output directory structure. can hydra step away from managing the directory structure in 1.0.0?

[omry]

@yukw777, nope. this is not something I am planning to do.
However, you can turn it off by changing hydra.run.dir to ".". you can also now disable the generation of the .hydra subdir.

Latest PL already have better support for Hydra working directory change. You see an issue now please file an issue here and tag me.

[yukw777]

@omry ah i see. reading the doc, you mean setting hydra.output_subdir to null right?

Also could you give me some details on how the latest PL provides "better support" for Hydra's working directory change?

[omry]

1. Yes.
2. Hydra provides an API to convert a relative path to be absolute taking the original working directory into account.
   PL is using that API when launching ddp jobs if Hydra is present to ensure it correctly gets the Python script path to execute.

There could be other cases where this gets in the way that we are not aware of any right now.
Generally speaking, if you run into rough edges when using PL and Hydra together I would prefer that you reach out with details about the problem:

1. There could be simple workaround you are not aware of.
2. This could prompt some changes to Hydra or PL in to better support for that use pattern.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.