You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently, we provide limited (and primarily undocumented) support for users to directly pass field objects to builds and make_config and do not make any assurances that we preserve any of the associated metadata. It also appears that we do not perform any value-validation on fields.
Thus I plan for us to:
Provide explicit support for passing field instances directly to our config-creation functions
ensuring metadata is preserved
ensuring parity with all validation that we perform
adding test cases that explicitly exercise fields-as-config-values
An edge case that I anticipate is that we might not permit fields as positional arguments.
Additionally ZenField should expose a metadata field. Ultimately ZenField is the same as dataclasses.field, except it can specify name and type as well; so perhaps we should expose all of the field options here, other than default_factory, which we handle automatically.
Lastly, if OmegaConf/Hydra does end up going this metadata route for supporting help messages, then we could potentially add a new feature to builds, where we can parse different styles of docstrings and auto-populate docs fields in metadata. This way, users need not duplicate any docs - the help messages will be derived directly from the source documentation!
The text was updated successfully, but these errors were encountered:
There is a sizeable demand for Hydra to support custom help messages through the CLI: facebookresearch/hydra#633
It appears that the leading candidate for supporting this, at least for structured configs, is via
dataclasses.field(..., metadata=<...>)
: facebookresearch/hydra#633 (comment) and omry/omegaconf#131 (comment).Presently, we provide limited (and primarily undocumented) support for users to directly pass
field
objects tobuilds
andmake_config
and do not make any assurances that we preserve any of the associated metadata. It also appears that we do not perform any value-validation on fields.Thus I plan for us to:
field
instances directly to our config-creation functionsfield
s-as-config-valuesAn edge case that I anticipate is that we might not permit
field
s as positional arguments.Additionally
ZenField
should expose ametadata
field. UltimatelyZenField
is the same asdataclasses.field
, except it can specify name and type as well; so perhaps we should expose all of thefield
options here, other thandefault_factory
, which we handle automatically.Lastly, if OmegaConf/Hydra does end up going this metadata route for supporting help messages, then we could potentially add a new feature to
builds
, where we can parse different styles of docstrings and auto-populate docs fields in metadata. This way, users need not duplicate any docs - the help messages will be derived directly from the source documentation!The text was updated successfully, but these errors were encountered: