Rodish is a generic argv parsing library. So named as the DSL it uses
is Roda-ish, and command line programs that would generally use it
would be running in something similar to "sh" (Bourne shell).
Rodish's Features:
* Designed to handle the needs complex CLI programs with multiple
levels of subcommands, with option parsing at each level.
* Option parsing at each level uses optparse (included in ruby's
stdlib or as a bundled gem).
* Unsupported options and invalid numbers of arguments result in
errors.
* Supports before hooks at every level. Before hooks are only
executed if the command is well-formed (passes optional/argument
handling at every level).
* DSL uses on/is, similar to Roda.
* Supports splitting up the subcommand handling into separate files,
similar to how the Roda hash_branches plugin works.
* Supports autoloading of subcommand files, similar to the Roda
autoload_hash_branches plugin works.
* Designed to be frozen in production, just like Roda.
* Significantly different from Roda internally, as it doesn't use the
same type of routing tree. Command blocks are executed inside a
provided context, but that is all. Reasons for this:
* CLI program arguments are generally not structured like the
URLs that Roda is designed to work best with. In general,
CLI programs wouldn't do:
ubi vm $vm_name ssh
They would do:
ubi vm ssh $vm_name
When the information that would allow you to take advantage of
a routing tree (being able to take actions during parsing
instead of after parsing) comes at the end of parsing, there
isn't a significant benefit to the routing tree.
* Option parsers are not cheap to setup, and creating one for
each argv parse for each subcommand level would be bad for
performance. This wouldn't matter for traditional CLI usage,
where the option parsing is only done once per process
execution, but we'll be using this in a Clover's api route
to parse argv submitted by clients.
* This allows introspection of the command tree. One way this
is exposed is to get the option parser usage text for all levels
in a single call. This will be useful to produce documentation
on each subcommand.
This could be open sourced at some point in the future, since it is
independent of Ubicloud.