"in our application tests [we need] to set an argument setting on all arguments programmatically just in the test context, and we had a lot of arguments so safest, cleanest, and easiest, to be able to set it with this new function. Essentially: app.mut_args(|arg| Some(arg.setting(ArgSettings::HideEnvValues)))". See #2966
AppSettings::AllArgsOverrideSelf is arg configuration that we want to apply everywhere. Rather than creating specialized arguments, is there a different way?
App::help_heading allows applying Arg:help_heading to all future arguments to take advantage of the natural grouping of arguments when adding them.
Note: in some cases, users will want this to apply globally (ie to all subcommand args)
Solution Options
Note: this isn't a "pick one" but we can use a mixture
Specialize Arg settings in App (ie do nothing), like
AppSettings::AllArgsOverrideSelf
App::help_heading
A App::next_display_order for #2808
Con:: design / implementation is needed for each solution
Con: each solution ends up different than the others
Direct users to use reflection + mut_arg to manually apply a setting (ie do nothing, see #2976)
This ended up being what we used instead of #2966 which led to it being reverted in #2994
Con: Not ergonomic for clap_derive users (instead of calling Parser, they have to call IntoApp and FromArgMarches)
Provide a App:args_mut(&mut self) -> impl Iterator<Item = &mut Arg>.
Con: Not ergonomic for clap_derive users (instead of calling Parser, they have to call IntoApp and FromArgMarches)
Provide a App::arg_setting
Con: Only works with ArgSettings, so doesn't help with AppSettings::AllArgsOverrideSelf or display_order
mut_args, modeled after mut_arg (see #2966, #2994)
Con: The return type is confusing (should it be just bool?)
Con: Policy of when to return what is unclear
Like mut_args above but Fn doesn't have a return type
mut_arg assumes you are calling it on an arg you intend to keep, so an implicit --version becomes explicit, making it show up when you might have disabled it
2966 carried this policy forward but provided a return value to avoid adding disabled args
This solution assumes that mass-setting an argument is argument-agnostic and it does not imply the intention of using that argument, so it keeps --version implicit
App::default_arg(arg: Arg) or App::mut_default_arg is layered underneath each arg
We'd have to implement support for tracking what arguments are explicitly set or not to know what is set in the "default arg" and what not to override in each arg
Not all settings should be layered (like alias or long)
App::override_arg(arg: Arg) or App::mut_override_arg is layered on top of each arg
We'd have to implement support for tracking what arguments are explicitly set or not to know what is set in the "override arg"
Not all settings should be layered (like alias or long)
For when to apply these to subcommands, we could
Have a global_ variant of any function, like today's `global_settings
Accept a global: bool or scope: enum Scope { Local, Inherit } argument in any function
Layer Subcommands on top of their immediate parent App
Like with default and override args, this will require tracking what configuration is explicitly set
Not all settings should be layered, like alias (used for subcommands)
epage
commented
2 years ago
Use Cases
app.mut_args(|arg| Some(arg.setting(ArgSettings::HideEnvValues)))". See #2966AppSettings::AllArgsOverrideSelfis arg configuration that we want to apply everywhere. Rather than creating specialized arguments, is there a different way?App::help_headingallows applyingArg:help_headingto all future arguments to take advantage of the natural grouping of arguments when adding them.Note: in some cases, users will want this to apply globally (ie to all subcommand args)
Solution Options
Note: this isn't a "pick one" but we can use a mixture
Argsettings inApp(ie do nothing), likeAppSettings::AllArgsOverrideSelfApp::help_headingApp::next_display_orderfor #2808mut_argto manually apply a setting (ie do nothing, see #2976)clap_deriveusers (instead of callingParser, they have to callIntoAppandFromArgMarches)App:args_mut(&mut self) -> impl Iterator<Item = &mut Arg>.clap_deriveusers (instead of callingParser, they have to callIntoAppandFromArgMarches)App::arg_settingArgSettings, so doesn't help withAppSettings::AllArgsOverrideSelfordisplay_ordermut_args, modeled aftermut_arg(see #2966, #2994)bool?)mut_argsabove butFndoesn't have a return typemut_argassumes you are calling it on an arg you intend to keep, so an implicit--versionbecomes explicit, making it show up when you might have disabled it2966 carried this policy forward but provided a return value to avoid adding disabled args
--versionimplicitApp::default_arg(arg: Arg)orApp::mut_default_argis layered underneath each argaliasorlong)App::override_arg(arg: Arg)orApp::mut_override_argis layered on top of each argaliasorlong)For when to apply these to subcommands, we could
global_variant of any function, like today's`global_settingsglobal: boolorscope: enum Scope { Local, Inherit }argument in any functionalias(used for subcommands)