We want to be able to list and document subcommands from the main ab launch program:
$ ab
Commands
ab run <abx>
ab help [<topic>]
ab wasm [<subcommand>]
ab version
The problem is, ab commands are implemented as executables on the user's path. To find a command, ab will find the exe named ab-<command> in the user's PATH. We could just list every program that starts with "ab-", but this won't work nicely with nested command trees. For example, ab wasm has it's own external subcommand executables (mangled as ab-wasm-<command>), which we don't want to list by default.
One potential strategy: rather than finding subcommands through the user's PATH environment variable, we can group plugins under a directory in libexec. Then, identifying the top-level commands becomes a matter of walking the libexec directory. Subcommands can be grouped using subdirectories.
Help strings and other metadata about each command could be pulled in a corresponding tree under usr/share/ab/, or even just as mangled man pages. Or, we could standardize on a CLI options, such as --help=short, and allow each subcommand to produce it's own script. The method to define help documentation should be simple and obvious, and this is starting to make installing commands a little complicated.
We want to allow commands to be implemented as scripts with shebangs, so we can't standardize on a binary format for plugins--commands should be plain old executables.
We want to be able to list and document subcommands from the main ab launch program:
The problem is, ab commands are implemented as executables on the user's path. To find a command, ab will find the exe named
ab-<command>in the user's PATH. We could just list every program that starts with "ab-", but this won't work nicely with nested command trees. For example,ab wasmhas it's own external subcommand executables (mangled asab-wasm-<command>), which we don't want to list by default.One potential strategy: rather than finding subcommands through the user's PATH environment variable, we can group plugins under a directory in libexec. Then, identifying the top-level commands becomes a matter of walking the libexec directory. Subcommands can be grouped using subdirectories.
Help strings and other metadata about each command could be pulled in a corresponding tree under usr/share/ab/, or even just as mangled man pages. Or, we could standardize on a CLI options, such as --help=short, and allow each subcommand to produce it's own script. The method to define help documentation should be simple and obvious, and this is starting to make installing commands a little complicated.
We want to allow commands to be implemented as scripts with shebangs, so we can't standardize on a binary format for plugins--commands should be plain old executables.