-
-
Notifications
You must be signed in to change notification settings - Fork 634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Retain the final defaults list in the Hydra config #956
Comments
I can add the final defaults list to the Hydra config object, which will allow you to interact with it. see |
Thank you. I missed |
Great. I will address this with 1.1, as small a change as it is I am done adding new features to 1.0. |
#1170 is adding a new fields to the hydra config: hydra:
choices:
group: choice
... This can be used in interpolation like: defaults:
- group: bar
key: ${hydra:choices.group} # bar, or any other choice if overridden. It also supports nested defaults (group1/group2) and config groups with overridden packages (group1@foo). |
#1170 is the biggest single feature in a single PR in Hydra. It's easily double in size of the second place. If you look at the long todo list in that PR you will see that documentation changes is still not done. |
🚀 Feature Request
Add an OmegaConf resolver for defaults, or allow value interpolation for defaults globally in a config by disabling deletion of the defaults key when Hydra loads a config.
tl;dr: add a
defaults
resolver, similar to thehydra
resolver.Motivation
Is your feature request related to a problem? Please describe.
Currently defaults can only be accessed from within the defaults list, as this portion of the config is deleted after being loaded by hydra.
For example, this currently works:
However, the following does not work:
This is not ideal when you want to obtain the name of a specific default to be used for example when you are logging.
_target_
that could otherwise be at the root of that config, but can't due to parameter conflicts.The current inconvenient way around this is:
The proposed way to do this would be:
However, the following does not work:
Pitch
Describe the solution you'd like
hydra
(eg.${hydra:job.name}
), this new resolver would be calleddefaults
and so to access the deleted${defaults.0.dataset}
you could use${defaults:0.dataset}
Describe alternatives you've considered
preserve_defaults=True
to stop the defaults key being deleted from the config when loaded by Hydra.Are you willing to open a pull request? (See CONTRIBUTING)
Unfortunately not, I do not have experience with the codebase.
Additional context
No additional context.
The text was updated successfully, but these errors were encountered: