Hey folks, I've been thinking recently about how CLIs are just functions, and the config (flags, envvars, config files) are just parameters.
Yet, I've never heard of an interface definition language for CLIs. It strikes me as potentially being very valuable:
- You could generate code that would allow the CLI to accept and handle the resolution of all three of envvars, flags, and config files (to enable full human and machine readability)
- The developer wouldn't have to manually deal with generating the 'PROPERTY1_2_SUBPROPERTY' syntax that 12-factor app development advocates for, but is a pain to understand
- It would allow for a formal API for the CLI, allowing for API breaks to be clear (for those who programmatically call the CLI)
- The idea of "routes" maps quite nicely to the "cli $subcommand [$subcommand] $verb ...flags..." pattern that docker and kubectl have set
- You could use it to generate language-specific CLI framework bindings, like Go's Cobra
- You could do documentation generation
- You could do generation of language-specific bindings for calling the CLI, so that calling the CLI as a subprocess is a function call in another language (rather than subprocess.call(["some","random","strings"]))
- You can calculate if changes to the CLI break the API for someone (thereby allowing for automatic semver)
Has anyone heard of something like this? Or should I build it?
0 comments
—
Ask HN: OpenAPI-like interface definition language for CLIs? · HackerTrans
Yet, I've never heard of an interface definition language for CLIs. It strikes me as potentially being very valuable:
- You could generate code that would allow the CLI to accept and handle the resolution of all three of envvars, flags, and config files (to enable full human and machine readability)
- The developer wouldn't have to manually deal with generating the 'PROPERTY1_2_SUBPROPERTY' syntax that 12-factor app development advocates for, but is a pain to understand
- It would allow for a formal API for the CLI, allowing for API breaks to be clear (for those who programmatically call the CLI)
- The idea of "routes" maps quite nicely to the "cli $subcommand [$subcommand] $verb ...flags..." pattern that docker and kubectl have set
- You could use it to generate language-specific CLI framework bindings, like Go's Cobra
- You could do documentation generation
- You could do generation of language-specific bindings for calling the CLI, so that calling the CLI as a subprocess is a function call in another language (rather than subprocess.call(["some","random","strings"]))
- You can calculate if changes to the CLI break the API for someone (thereby allowing for automatic semver)
Has anyone heard of something like this? Or should I build it?