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
It would be nice to have an extra layer of abstraction between module parameters and pipeline parameters. Use cases:
ability for pipelines to give user-facing names to their parameters that are used by the outside world. Currently, one must use the <module_name>.<parameter_name> syntax in pipeline requests
ability to perform some manipulation on the user-provided pipeline parameter value to construct the actual module parameter. For example, if the module parameter is a large Config, like, say, eta.core.annotations.AnnotationConfig, and I want to write a pipeline that exposes one of these fields directly to the end user without forcing them to provide an entire AnnotationConfig
The text was updated successfully, but these errors were encountered:
It would be nice to have an extra layer of abstraction between module parameters and pipeline parameters. Use cases:
ability for pipelines to give user-facing names to their parameters that are used by the outside world. Currently, one must use the
<module_name>.<parameter_name>
syntax in pipeline requestsability to perform some manipulation on the user-provided pipeline parameter value to construct the actual module parameter. For example, if the module parameter is a large
Config
, like, say,eta.core.annotations.AnnotationConfig
, and I want to write a pipeline that exposes one of these fields directly to the end user without forcing them to provide an entireAnnotationConfig
The text was updated successfully, but these errors were encountered: