Representing Dynamic Arguments #6

Here's what we did for the dotnet CLI's static completion script generation. @slang25 is right that we needed a sort of 'marker' to signal to each of the shell-specific implementations that "you need to go run a command here to get more data". The part that we're missing from the overall implementation, and the part I need to solve before spinning the entire csproj off as a library built on top of S.CL, is figuring out a good way to tell the shell-specific generators what that command to run should be. Right now it's hard coded to 'dotnet complete', but you could imagine any number of options for individual CLIs fitting here. It's also possible that this library might auto-include a default completions command similar to 'dotnet complete' so that commands don't need to rely on 'dotnet-suggest' being installed, etc.

I think a reasonable approach would be to restrict "call this to get list of permissible values" to commands from the same spec. After all, we can assume little about the runtime environment besides the program at hand being available.

Sketching for docker image rm:

"commands": [
 {
 "name": "rm",
 "arguments": [
 {
 "name": "IMAGE",
 "description": "The image ID to delete",
 "required": true,
 "acceptedValues": {
 "command": [ "image", "ls", "--quiet" ]
 }
 }
 ],
 }
]

as opposed to acceptedValues.enum: [ "a", "b", "c" ] (which would replace the current acceptedValues: [ "a", "b", "c" ].
[docker] image ls would have to be a (sub)command from the same spec, with option --quiet.

This should enable

• validation of the spec ("is that command valid itself?"),
• generation of completion scripts ("call the given command and use its output"), and
• code generation ("call the method that implements that command").

(I'm fully aware that this sketch wouldn't be good enough for docker completions; we'd want to see tags, not IDs! Well, I'll say this: a standard like the above might actually force developers to provide easy commands to get scriptable output ...)