Skip to content

Find a way to make external subcommands discoverable #4

Open
@rwy7

Description

@rwy7

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions