Short subcommand names

[ALPSMAC]

First off - decline is the most usable and sensible CLI parsing library in the Scala ecosystem I've encountered to date - so thanks for that! :-)

Summary:

It would be great if when parsing the library could match on a subcommand when enough letters are specified to uniquely identify the subcommand.

Example:

As a toy example, consider re-implementing bits of the kubectl cli:

lazy val get: Command[Observable[String]] = Command[String](
      name = "get",
      header = "Get resources from the k8s API"
    )(Opts.subcommands(
      get_pods,
      get_statefulsets,
      get_services,
      ...
    ))

It would be nice to trigger execution on get po or get st or get se instead of having to spell out the full resource each time.

Motivation:

For example, in the "real" kubectl, I can do something like kubectl get po rather than kubectl get pods. For CLIs that are complex and heavily used it's nice to be able to trim characters wherever possible. It's probably not part of the POSIX standard, but it certainly does improve quality-of-life for end users and seems prevalent enough in the different CLI tools I've encountered over the years.

Suggestion:

Could perhaps be implemented as an optional behavior - e.g.: Opts.subcommands(..., partialMatch = true)

Disclaimer:

I know Opts is implemented as an Alternative right now. I won't claim to have thought much about whether or not this parsing change would influence that... gut says probably not, but if the answer is "can't get there from here - algebra laws won't allow it" that's fine too.

Also - this could be related to #52 - may need similar matching logic in place (somewhere) for bash completion. Possible that the partial subcommand logic belongs there instead of as a built-in on the library itself... not sure.

[bkirwi]

Thanks, glad you've enjoyed!

Bit torn over this request, because I believe allowing arbitrary command shortenings usually isn't worth the loss in clarity that you get for the convenience. (And explicit aliases are easy to implement.) However, I think this meets all my usual criteria for inclusion: similar things a long history of use in other tools, including the GNU standards for long options which we mostly follow; does require being baked in to some extent from what I can see; and doesn't impact existing users too badly. (I don't expect this to break Alternative laws, but the tests do occasionally surprise me...)

A few thoughts:

• If you do this for commands, you'd probably want to do it for options and flags too, since that's GNU-standard and has similar motives.
• I suspect this also makes sense as a flag to parse, or some sort of new parseAbbreviated. Having some subcommands be autocompletable and others not would be pretty surprising. (And I'd be disinclined to make it default behaviour.)
• The natural place to implement the main logic would be Parser.scala. You'd need to change the individual flag or option parsers to allow prefix matches, and all the combinators to prefer full matches over partial matches. You'd also need to extend stuff like the Match classes to track the full list of names options or flags that had the given string as a prefix (so we can report errors well) plus something for commands. Kind of tedious, but not especially daunting.
• We'd want to add a sentence or two to the guide, and maybe an example.

I'm unlikely to do this personally, but PRs are welcome!

[ALPSMAC]

Ben,

Thanks for the info. If I can ever shake free a few spare cycles myself I'd be willing to give a PR a shot. I'll let you know if/when I'm able to try.

FWIW I've been spending the last two days converting a rather complicated CLI we have that was using scallop over to decline and I have to say that the decline version is (thus far) considerably more readable and maintainable.

Kind Regards,
Andy