tools.cli

Optionally allow unkown options

Details

  • Type: Enhancement Enhancement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Declined
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

When building a cli with subcommands, it can be useful to allow passing through unkown options as arguments, so they can be processed in a subcommand.

The current API doesn't allow for passing any configuration to the `cli` command, so this adds an `allow-unknown-opts?` var, which when bound to true, will pass through unknown options.

Activity

Hide
Hugo Duncan added a comment -

A patched version of tools.cli is available on clojars as `[com.palletops/tools.cli "0.2.4"]`

Show
Hugo Duncan added a comment - A patched version of tools.cli is available on clojars as `[com.palletops/tools.cli "0.2.4"]`
Sung Pae made changes -
Field Original Value New Value
Assignee Gareth Jones [ gar3thjon3s ] Sung Pae [ guns ]
Hide
Sung Pae added a comment -

Hello,

In the next version of tools.cli, parse-opts accepts an :in-order option to process arguments sequentially until the first unknown token.

The README has an explanation:

https://github.com/clojure/tools.cli#in-order-processing-for-subcommands

This is not the same as passing through unknown options, but it is the convention I am familiar with in large programs with subcommands.

Is this solution satisfactory for you?

The only times I have ever implemented a pass-through option for an options parser was for programs that wrap other command line programs. In these cases, the wrapper had a possibly intersecting superset of options, and I wanted to provide access to the underlying command's options without specifying them in my wrapper.

This worked okay, but the resulting options interface was complex, and since the relationship of the wrapper and underlying command was implicit, a bit fragile.

A major problem with the superset parser was that all unknown options were assumed to require arguments. This is necessary because it is impossible to tell whether `-ab` is meant to be interpreted as `-a -b` or `-a "b"` without knowing whether `-a` requires an argument. We can work around this by requiring that pass-through options always specify option arguments with an equal sign, but now we have introduced subtle differences for different tiers of options.

In contrast to all that, the subcommand options processing style of the git program and others like it allow many intersecting sets of options to be present in a single command invocation simply by following the easily understood convention:

cmd [cmd-opts] subcmd1 [subcmd1-opts]

I hope you find this argument persuasive, but I am happy to discuss it further!

Show
Sung Pae added a comment - Hello, In the next version of tools.cli, parse-opts accepts an :in-order option to process arguments sequentially until the first unknown token. The README has an explanation: https://github.com/clojure/tools.cli#in-order-processing-for-subcommands This is not the same as passing through unknown options, but it is the convention I am familiar with in large programs with subcommands. Is this solution satisfactory for you? The only times I have ever implemented a pass-through option for an options parser was for programs that wrap other command line programs. In these cases, the wrapper had a possibly intersecting superset of options, and I wanted to provide access to the underlying command's options without specifying them in my wrapper. This worked okay, but the resulting options interface was complex, and since the relationship of the wrapper and underlying command was implicit, a bit fragile. A major problem with the superset parser was that all unknown options were assumed to require arguments. This is necessary because it is impossible to tell whether `-ab` is meant to be interpreted as `-a -b` or `-a "b"` without knowing whether `-a` requires an argument. We can work around this by requiring that pass-through options always specify option arguments with an equal sign, but now we have introduced subtle differences for different tiers of options. In contrast to all that, the subcommand options processing style of the git program and others like it allow many intersecting sets of options to be present in a single command invocation simply by following the easily understood convention: cmd [cmd-opts] subcmd1 [subcmd1-opts] … I hope you find this argument persuasive, but I am happy to discuss it further!
Hide
Hugo Duncan added a comment -

The new `:in-order` option provides a better solution.

Show
Hugo Duncan added a comment - The new `:in-order` option provides a better solution.
Sung Pae made changes -
Status Open [ 1 ] In Progress [ 3 ]
Hide
Sung Pae added a comment -

Thank you for your thoughts on this.

Show
Sung Pae added a comment - Thank you for your thoughts on this.
Sung Pae made changes -
Resolution Declined [ 2 ]
Status In Progress [ 3 ] Resolved [ 5 ]

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: