Arguments for a set of subcommands

[Frando]

We have this requirement: Our app has a few subcommands. Some of them share a few arguments. We would like to process these shared argument at the top level, before calling handlers for the individual commands. Is this possible?

This is what I currently have:

#[derive(Parser, Debug, Clone)]
struct Cli {
    #[clap(subcommand)]
    command: Command,
    #[clap(long, default_value_t = DEFAULT_RPC_PORT)]
    rpc_port: u16,
    #[clap(long, default_value_t = DEFAULT_BIND_ADDR)]
    bind_addr: SocketAddr,
}

#[derive(Parser, Debug, Clone)]
pub enum Command {
    #[clap(flatten)]
    Node(#[clap(subcommand)] NodeCommand),
    #[clap(flatten)]
    Rpc(#[clap(subcommand)] RpcCommand),
}
#[derive(Subcommand, Debug, Clone)]
pub enum NodeCommand {
    Start,
    Get
}
#[derive(Subcommand, Debug, Clone)]
pub enum RpcCommand {
    Status,
    Add,
    // ...
}

This works, however what I'd want is that the rpc_port option only applies to the commands in RpcCommand and the bind_addr only applies to the commands in NodeCommand. I care less about this being reflected in code, but more that the help shows this correctly - and ideally clap would error if the option is supplied where it may not be present.

Is this possible?

[epage]

From a CLI design perspective, it seems to me like an argument that only applies to some subcommands shouldn't be "above" the subcommands but "underneath" them.

Is there a reason you are putting them at the top-level?

[epage]

For the immediate question, the answer is "there isn't a built-in way".

This can be handled on the users end by

• Putting the arguments into a help_heading that is named after the subcommand
  • Or providing a custom help / help template
• Doing the validation on your side
  • This would require using Option for the arguments, rather than setting a default, since you don't have access to ArgMatches::value_source (derive: Store indices, value source next to field values #3846)

In terms of the features we support, we need to balance ease of use, build time, and binary size (which all encourage fewer features) with flexibility. We try to strike this balance by asking (1) what the CLI best practices are that we should be encouraging and (2) can exception cases be worked around. In this case, the exception case can be worked around. We are considering making clap's design more open-ended (#3476) though that will have a degree of boilerplate to it unless a pattern becomes common enough for people to provide in a library, making the workaround a better route.

[Frando]

Thank you very much for your response!
The reason I wanted to have the options above the subcommands is that it would make our code a bit simpler, because we also use the same command enums in a REPL, where the rpc client for the rpc commands is persisted between the commands, and we have a RpcCommand::run(rpc_client: RpcClient) method. This would be easier to do if the rpc_port option lives at the top level to create the RPC client at the same place in the code for all RPC commands.

I will think through the available options, and am looking forward to progress on #3476 .