Skip to content
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

Find a way to make external subcommands discoverable #4

Open
rwy7 opened this issue Sep 26, 2019 · 0 comments
Open

Find a way to make external subcommands discoverable #4

rwy7 opened this issue Sep 26, 2019 · 0 comments

Comments

@rwy7
Copy link
Member

rwy7 commented Sep 26, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant