Better support chaining multiple enums for subcommands without arguments

[leotaku]

In the wild, I often see command line applications that group related commands under a single subcommand that takes no arguments.

Currently, this seems to be achievable in two ways. I have tried to illustrate them in the Example section.

Now I would personally argue that the second way of implementing a subcommand without arguments is perfectly valid and prettier than the first one. However, it has the ugly flaw of panicking whenever the subcommand is called without another subcommand. This can be fixed by adding AppSettings::SubcommandRequiredElseHelp to the subcommand in question.

So would it maybe be possible, or even desirable, for clap to automatically behave as if AppSettings::SubcommandRequiredElseHelp was set when Clap is derived for an enum value?

Thank you for your hard work on clap!

Example

• app (--verbose, ...)
  • config
    • show
    • edit
  • ...

Version 1

First, the more verbose way.

#[derive(Clap)]
pub struct App {
  #[clap(long = "verbose")]
  verbose: bool,
  // ...

  #[clap(subcommand)]
  subcommand: Subcommand,
}

#[derive(Clap)]
pub struct Subcommand {
  Config(Config)
  // ...
}

#[derive(Clap)]
pub struct Config {
  #[clap(subcommand)]
  subcommand: ConfigSubcommand
}

#[derive(Clap, Debug)]
pub enum ConfigSubcommand {
   Show,
   Edit,
}

Version 2

But because the config subcommand does not take any additional values, this is also possible.
Unfortunately this code will panic when no argument is given to the config subcommand.

#[derive(Clap)]
pub struct App {
  #[clap(long = "verbose")]
  verbose: bool,
  // ...

  #[clap(subcommand)]
  subcommand: Subcommand,
}

#[derive(Clap)]
pub struct Subcommand {
  Config(Config)
  // ...
}

#[derive(Clap, Debug)]
pub enum Config {
   Show,
   Edit,
}

Version 2 (fixed)

This problem can however be fixed by adding AppSettings::SubcommandRequiredElseHelp to the config subcommand.

#[derive(Clap)]
pub struct App {
  #[clap(long = "verbose")]
  verbose: bool,
  // ...

  #[clap(subcommand)]
  subcommand: Subcommand,
}

#[derive(Clap)]
pub struct Subcommand {
  Config(Config)
  // ...
}

#[derive(Clap, Debug)]
#[clap(setting = AppSettings::SubcommandRequiredElseHelp)]
pub enum Config {
   Show,
   Edit,
}

[CreepySkeleton]

So would it maybe be possible, or even desirable, for clap to automatically behave as if AppSettings::SubcommandRequiredElseHelp was set when Clap is derived for an enum value?

And we actually do that so long as the subcommand in question isn't optional. This is a bug, could you please file an issue?

[leotaku]

Will do! I simply assumed that this might be expected behavior and warrant further discussion, so I did not open an issue immediately.

I have never used the GitHub discussions feature before. Just for future reference, should I open an issue for cases like this, or is the discussions feature preferred?

[CreepySkeleton]

There's no hard rule.

We've opted to GH discussions because we were bombarded by questions that landed to our issues tracker, and that was quite a mess. Furthermore, discussions are more convenient for, well, discussions due to this neat branching style.

So, there's no strict line in the sand or something. Some sensible rules of thumb:

• If you are reasonably sure that something behaves in a way it shouldn't, you can bypass discussions and proceed to reporting the bug to the issues tracker. Bad/wrong error messages are also bugs.
• If you want to do something that is either impossible or too tedious with the current tooling and you are reasonably sure (yeah, I need to work on my vocabulary) this feature/improvement might be useful for a good number of users (i.e it's not some niche use case), file a feature request.
• If you want to just ask maintainers about *thing*, use discussions.
• If you aren't so certain, err on the side of discussions.

Footnote: as a general advise, "ask for forgiveness, not for permission" is very true. It's better to file an allege bug that will prove wrong than hesitate and keep suffering because of it. We have means to convert an issue into a discussion, so don't be afraid to break something.