Upgrade to Hydra 1.0

[omry]

Hello,
I released Hydra 1.0.0rc1 about a week ago.

I suggest that you use it for this project.
Check out the release notes.

It is still a release candidate, but as I get more feedback about it and address new issues it will become the primary version.

[mchiquier]

Great, thank you

[goodmattg]

@omry Does Hydra 1.0.0rc1 support loading StructuredConfig's from a python file, instead of yaml? Looking at OmegaConf 2.0, the typing in StructuredConfig is great, but I don't see any functionality for Hydra to load non-yaml files

[omry]

@goodmattg:
Yes.
The website contains two versions of the docs, stable and next. look at next .

There is an entire new tutorial dedicated to Structured Configs.

[goodmattg]

@omry Thanks for the link to the new docs; the Structured Config documentation looks good. I'm sure you frequently get this question, but is there planned future support for user methods?

One of the few patterns I wanted to include from argparse for this boilerplate is defining the type as a function. E.g. specifying the type of a data path argument as a function checking that the path is valid, rather than a string.

[omry]

@goodmattg , Structured Configs are new, so no - it's the first time someone ask for it.

Generally speaking, OmegaConf is not open to arbitrary types, and at the moment there is no way to extend the types it supports. (the list includes primitives like int,float, bool, string and Enums, as well as dicts, lists and dataclasses or instances containing those types).

Supporting user methods in Structured Configs would not mean that you can put arbitrary user data in the config.

With respect to further validation:
I am planning to try to add support for pep 593 annotations and add some additional validators.
See rough details here.

For the time being you can do the validation on your side, and when (if) 131 is implemented you will be able to offload it to OmegaConf.

[goodmattg]

@omry struggling with something that feels trivial looking at the documentation. We want to access hydra.runtime.cwd in our config. I can see the field running python ... --cfg job, but no luck getting this into a .yaml config. I expected to put something like: orig_cwd: ${hydra:runtime.cwd} in our yaml file.

Any help is appreciated!

[omry]

What do you mean by "no luck getting this into a .yaml config"?

Please be more specific, ideally even provide a minimal example.

[goodmattg]

Specifically, I would like to populate a yaml field with the value of hydra.runtime.cwd. While I know I can access the field by copying to an environment variable:

hydra:
  job:
    env_set:
      ORIG_CWD: ${hydra.runtime.cwd}

then access with os.environ["ORIG_CWD"] in code.

I would prefer to set a field in our config.yaml:

orig_cwd: ${hydra.runtime.cwd}

then access with cfg.orig_cwd in code. Is this possible?

[omry]

You are talking about multiple things:

1. populating a yaml file.
2. Accessing a field in the config with the original cwd:
   Here is how you do both:

config.yaml:

cwd : ${hydra:runtime.cwd}

app.py:

import hydra
from omegaconf import DictConfig, OmegaConf
import os

@hydra.main(config_name="config")
def my_app(cfg: DictConfig):
    print("Accessing hydra cwd from config: ", cfg.cwd)
    print("Populating yaml file hydra cwd: ", os.path.join(os.getcwd(), "config.yaml"))
    OmegaConf.save(cfg, "config.yaml", resolve=True)
    print(
        "Accessing hydra.cwd through API: ", hydra.utils.get_original_cwd(),
    )

if __name__ == "__main__":
    my_app()

on a side note, feel free to ask these kind of questions on Stack overflow under #fb-hydra or #omegaconf