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
To support the improvements being made to the model-check tool in #315, it would be helpful if the InputSpec interface (from the build package) included an optional inputId property.
When the inputId is defined, it provides a more resilient way to compare a scenario between two versions of the model even if the variable is renamed.
The plugin-config package already includes an id column in inputs.csv for this purpose, so we just need to include that when initializing the InputSpec for each row.
Proposed API:
exportinterfaceInputSpec{/** * The stable input identifier. It is recommended to set this to a value (for example, a * simple number like what `plugin-config` uses) that is separate from `varName` and is * stable between two versions of the model. This way, if an input variable is renamed * between two versions of the model, comparisons can still be performed between the two. * If a distinct `inputId` is not available, plugins can infer one from `varName`, but * note that this approach will be less resilient to renames. */inputId?: string// ...}
The text was updated successfully, but these errors were encountered:
To support the improvements being made to the model-check tool in #315, it would be helpful if the
InputSpec
interface (from thebuild
package) included an optionalinputId
property.When the
inputId
is defined, it provides a more resilient way to compare a scenario between two versions of the model even if the variable is renamed.The
plugin-config
package already includes anid
column ininputs.csv
for this purpose, so we just need to include that when initializing theInputSpec
for each row.Proposed API:
The text was updated successfully, but these errors were encountered: