Subcommand dispatch¶
Route a parsed command to a handler, optionally typed per command path. See the Subcommand dispatch guide.
Dispatch ¶
Route a parsed command to a handler - the subcommand dispatch docopt itself omits.
Register one handler per command path with on. run
then parses argv and calls the handler for the most specific command path that matched.
The handler receives the parsed Arguments, or an instance of schema bound from the result when
the registration supplies one, so each subcommand gets its own typed view. An on() with no command
path registers a fallback, used when no more specific path matches.
Example
app = Dispatch(doc); @app.on("user", "create") def create(args): ...; app.run().
Source code in src/docopt2/_core.py
on ¶
Register the decorated handler for command_path (empty path = fallback handler).
Source code in src/docopt2/_core.py
run ¶
Parse argv against the doc and invoke the handler for the matched command path.
Extra keyword arguments are forwarded to docopt (suggest, exit_code, ...).
schema is not among them, since dispatch matches on the mapping and binds per handler.
Source code in src/docopt2/_core.py
check ¶
Statically lint the usage message and the table, before any argv is parsed.
Returns what check returns for the usage message, and for every handler registered
with a schema what check(doc, schema=...) returns, with one difference: the schema is held against
the usage lines its handler can be run for, and not against the whole usage. So an element that only
the lines of another command leave out is not reported as one that may be absent. Each such finding
names its handler. A line is held whole: where one line serves two commands, (add <name> | list),
<name> may be absent on it for the handler of add too.
A handler that no argv can reach is reported too: an "error" where its command path names what the
usage does not have, a "warning" where another handler is the one run for every argv that gives
its commands. A fallback, registered with no command path, is never reported.