-
Notifications
You must be signed in to change notification settings - Fork 30
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
Refactor input: arg
for improved UX/Schema
#218
Comments
From verbal discussion and investigation: Proposal
Pseudo-schema# <HOST>/<PREFIX>/<VERSION>/definitions/inputKind.yaml
type: string
enum: [arg, env, stdin] # <HOST>/<PREFIX>/<VERSION>/definitions/commandArgs.yaml
type: array
items:
type: [string, object]
required: [type, name]
properties:
type:
title: Argument Type
description: Defines which handler DSC should use for the argument.
type: string
enum: [input, debug, verbose, whatif]
name:
title: Argument Name
description: Defines the name of one or more options to insert for the argument.
type: array
items: { type: string }
minItems: 1 # <HOST>/<PREFIX>/<VERSION>/resource/manifest.set.yaml
type: object
required: [executable, input]
properties:
executable: { $ref: /<PREFIX>/<VERSION>/definitions/commandExecutable.yaml }
args: { $ref: /<PREFIX>/<VERSION>/definitions/commandArgs.yaml }
input: { $ref: /<PREFIX>/<VERSION>/definitions/inputKind.yaml }
return: { $ref: /<PREFIX>/<VERSION>/definitions/returnKind.yaml }
implementsPretest: { type: boolean, default: false }
# if input=arg, require the input-type object, else forbid it.
allOf:
- if: { properties: { input: { const: arg } } }
then:
properties:
args:
contains: { type: object, properties: { type: { const: input } } }
minContains: 1
maxContains: 1
else:
properties:
args:
not: { contains: { type: object, properties: { type: { const: input } } } } |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary of the new feature / enhancement
In #213 we added functionality for defining an input kind that passes the instance property bag JSON to an executable by replacing a templated argument in the list:
DSC/dsc_lib/src/dscresources/resource_manifest.rs
Lines 51 to 62 in 5b92b58
I'm not sure about this change/implementation from the user-facing perspective and the schema - it moves the schema from a set of enum values (in JSON Schema syntax) to a
oneOf
that is more complicated and harder for users to adjust/grok.Compare the three available input kinds for the
get
command:The latter option requires the author to:
input
as an object with the propertyarg
set to that string value instead of as a string.This both complicates the JSON schema and adds a (small) complexity of choice where I'm not sure it fully matters. It also makes supporting full IntelliSense and contextual help during the authoring process more difficult, as we can't rely on the
markdownEnumDescriptions
metadata in the same way.Proposed technical implementation details (optional)
I would propose an enum value like
Arg
(arg
in the JSON) that always replaces a static string argument in the list, instead of allowing an arbitrary string. If that static string argument isn't included, we could either error (the manifest is invalid) or add the JSON as the last argument, after all defined arguments.We could have that argument string be something like
{{instance_json}}
to be very unlikely to conflict with any actual arguments.Then the manifest would look like:
From a schema perspective, we can then validate that when
input
isarg
thatargs
includes the static string and not wheninput
is any other value.Here's a sample of the schema definition, assuming no implicit handling:
This would make defining the commands more unified across input types, easier to provide IntelliSense/validation/contextual help for, and simplify manifest authoring.
The primary drawback to this that I see is for resources that can't use the static string for the replacement. Are there cases where users will need to specify a custom value for the replacement string? I can't think of any.
This change also allows, but does not require, handling the input JSON argument implicitly as the last argument. I think the implementation change can/should be made regardless of whether we decide to support the implicit argument case.
The text was updated successfully, but these errors were encountered: