-
-
Notifications
You must be signed in to change notification settings - Fork 644
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
Recursive instantiation #566
Comments
Is the New style intended to replace the current one? |
Not entirely. If you don't own the the dataclass you will not be able to add the type field to it. |
Okay my original concern was if we could keep around the |
we may want to deprecate it in favor of
|
Looks good! |
This is coming in Hydra 1.1. I would like to make recursive instantiation the default, but this is a breaking change for people that are actually interested in it because right now they are getting the nested config as a config and they need to manually call instantiate on it. Like this comment to indicate yes and dislike it to indicate no. |
I second having this be the default behavior. For me personally it is an acceptable breaking change, since it allows to have portable code (that does not depend on Hydra) and use Hydra on top for configuring. Currently, calling instantiate manually breaks the modularity since we can only instantiate via Hydra this way (and we would like to be able to do both). |
Can you explain more how instantiate behaving one way or another interacts with your ability to do things outside of Hydra? |
This is now in Hydra master branch. |
this would go well with a change to the config definition of an instantiated object:
Current
New
Once this is implemented, we can describe recursive instantiation like:
An remaining open question is how to support passthrough for nested objects.
Currently, passthrough can override individual values:
a possible approach is for nested objects is to use a dictionary:
The text was updated successfully, but these errors were encountered: