Declare CLI options as global

[theredfish]

I'm working with the CustomCli and I use cargo aliases. It would be handy to have the default cli options declared as global so we can access them via the subcommands directly.

I created a draft example here. I introduced a subcommand smoke and changed the options to be global.

You can run the test cli like this :

• Without global option : cargo test --package cucumber --test cli -- smoke --report-name "test"
• With the fail-fast global option : cargo test --package cucumber --test cli -- smoke --report-name "test" --fail-fast

Seems to work correctly. Do you think it's ok? Maybe there are some side effects I didn't think about. Maybe there is a better way to handle this need?

[tyranron]

@theredfish seems like a reasonable improvement. Would be nice to see this as a separate PR.

@ilslv it seems that it won't break anything. Could you confirm this?

[ilslv]

@theredfish I'm concerned that this can lead to the issue described in clap-rs/clap#3721. Is this the only way to let users have subcommands and provide cucumber default cli options? Doesn't cargo test --package cucumber --test cli -- --fail-fast smoke --report-name "test" work without global options now?

[theredfish]

I'm not sure to see exactly what's the issue with the design even after reading the explanations? Isn't it intended to have global options accessible with or without the subcommand?

cargo test --package cucumber --test cli -- --fail-fast smoke --report-name "test" works perfectly indeed. But when you use cargo aliases for example, let's say smoke, then you don't have access to the base options since you're already in the subcommand part.

Ex of toml file with aliases (it doesn't reflect a real alias case but I kept the same command I used in the discussion) :

[alias]
smoke = "test --package cucumber --test cli -- smoke"

then if the options are not global, you can't access for example the --fail-fast flag. Ideally I would like to use it like this with the alias :

cargo smoke --report-name "test" --fail-fast

Hope it makes sense regarding the need. But I can understand the concerns if there are some risks of clashes. But I'm not sure to see how it's a bad design to have global options with required commands.

[tyranron]

@ilslv

I'm concerned that this can lead to the issue described in clap-rs/clap#3721.

Well, users still can hit this issue by providing custom global CLI options along with custom subcommands. I don't see this being a critical one.

[ilslv]

@theredfish thanks for a more detailed explanation! After reading it, seems like described issue shouldn't affect any users ever (and even if it does, it's just a help message after all), so I'm in favor of this feature being implemented.