[Bug] Unable to return any value from main function

🐛 Bug

Once marked with @hydra.main, the function always returns None.

To reproduce

** Minimal Code/Config snippet to reproduce **

@hydra.main(config_path='config.yaml')
def main(cfg):
    return 1

if __name__ == '__main__':
    always_none = main()
    print(always_none)   # always print None

Expected Behavior

Expects value to be returned like the usual functions do.

System information

• Hydra 0.11.2

• Python 3.6.6

• Ubuntu 18.04

[Jasha10]

Hi @fabrizioschiano,

The @hydra.main decorator is designed to wrap around your program’s main entrypoint. Think of this main entrypoint as being similar to the main function from C/C++/Java.

You should checkout the compose API. This functional API will allow you to get a config from Hydra and do whatever you want with it.

The drawbacks of using the compose API (instead of the @hydra.main decorator) are:

• no support for command line completion
• no automatic support for saving your config file to the outputs directory
• no --multirun support

The @hydra.main decorator is designed specifically to support the above use-cases.

[alvitawa]

I understand that it is a best practice to do everything inside the hydra main function, but nevertheless there are situations where it is useful to be able to simply return something. For example in my app I have all the logic inside the main function, but I want the result of the main function to be available in the repl after running the script with python -i. This is done with:

if __name__ == "__main__":
    register_configs()

    cfg, result = main()

This way I can play around with the result of the script to check if it is correct or save it if it is good.

However, @hydra.main not returning a function forces me to do this through global variables which is messy. And let’s not forget the time it has cost me to figure out why my main function was always returning None.

I think it is preferable if libraries don’t force the user to use them in a particular way but instead allow the user to use the library in the way that is most suitable for his/her application.

I realize I’m being a bit philosophical here but another area in which this manifests is with the custom tracebacks that are provided. It is fortunate that you provide a flag to disable them (‘export HYDRA_FULL_ERROR=1’) but personally I wonder why a library meant for application configuration also hooks into your error tracebacks (and in the meantime prevents you from using post mortem debugging unless you disable the custom tracebacks).

Anyways, I just wanted to give my experience with hydra with regards to this.