-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for automatic negation flags #815
Comments
Great proposal @kbknapp. Having a Perhaps this could even be the default, considering that v3 is still in beta? The user would then have to call |
Not all single flags are need overridable flags. From looking at the clis, this is a minority use case. Which is why this won't be a default behaviour. |
With the new Arg::new("force")
.action(clap::builder::SetBool)
.long("force")
.alias("no-force") The
The downside is you wouldn't be able to control whether shorts would set true or false. |
In xh we support negating all options, not just boolean options. The prefix check feels too magical, if I found that example in the wild I wouldn't know where to look for an explanation. |
Thanks for bringing up this use case. I don't tend to see this too often. Even if we don't provide a native way of supporting it, there would always be Speaking of, how are you implementing that today? I looked at your
I can understand. It is dependent on people thinking to check the the documentation for |
See a few comments back: #815 (comment) The new reflection came in very handy! |
Oh, I had overlooked in that comment that you meant negations for all options and not just flags. |
Coming from the Python
@epage is it possible to define our own actions apart from the included standard ones? I couldn't find any examples for this so if you could point me to one, that'd be very helpful. |
Not currently. but I think I saw something saying that was on the roadmap. |
@dhruvkb the plan is to eventually support it but not yet. Current blockers:
|
I'll subscribe to the issue for updates. In the meantime I've got a variant of @blyxxyz's snippet working for me. Thanks! |
While I don't think this is the way we should go, I thought I'd record how CLI11 solves this problem: runtime parsing of a declaration string. See https://cliutils.github.io/CLI11/book/chapters/flags.html |
I'd really like this to render as `--preview / --no-preview`, but I looked for a while in the Clap internals and issue tracker (clap-rs/clap#815) and I really can't figure out a way to do it -- this seems like the best we can do? It's also what they do in Orogene. Closes #7486.
Hi, is there any updates? Thanks! Especially, it would be great to have one in Parser derivation mode, instead of the builder mode. P.S. I found https://jwodder.github.io/kbits/posts/clap-bool-negate/ but the workaround is not super neat IMHO |
FWIW, in xh we've moved to a still cleaner implementation by enabling clap's let negations: Vec<_> = app
.get_arguments()
.filter(|a| !a.is_positional())
.map(|opt| {
let long = opt.get_long().expect("long option");
clap::Arg::new(format!("no-{}", long))
.long(format!("no-{}", long))
.hide(true)
.action(ArgAction::SetTrue)
// overrides_with is enough to make the flags take effect
// We never have to check their values, they'll simply
// unset previous occurrences of the original flag
.overrides_with(opt.get_id())
})
.collect();
app.args(negations)
.after_help("Each option can be reset with a --no-OPTION argument.") It no longer feels like a hacky workaround so I'm pretty happy with it. It's cool how flexible clap has become. |
For my specific use-case, it would be perfect for me if I could use |
In my experience you only use |
Thank you! That looks helpful |
If the #[derive(Parser)] could implement a boolean flag like Python click, @click.option('--color/--no-color', default=False)
@click.option('--enable-option/--disable-option', default=False)
@click.option('--with-something/--without-something', default=False) Imagine: /// Given that the default value is true, providing a short option should be considered as false. And vice versa.
#[arg(short = "C", long = "--color/--no-color", default_value = "true")]
color_flag: bool,
/// Explicitly providing a short option maps to true/false.
#[arg(short = "o/O", long = "--enable-option/--disable-option", default_value = "true")]
some_option_flag: bool, |
Would love to see this added! |
Add a way to automatically generate flags that override (or negate) other flags. This can be done manually already, but doing so for an entire CLI can be tedious, painful, and error prone. Manually doing so will also pollute the
--help
output.This proposal offers a way to automatically have these negation flags generated on a case by case basis, or across all flags in the command. This proposal also offers a way to have these negation flags listed in the
--help
message or hidden.Design
A negation flag would simply take the long version of the regular flag and pre-pend
no
; for exmaple--follow
would get a--no-follow
. If a flag only specifies a short version, theno
would be prepended to the short such as-L
gets--no-L
.When parsing occurs, if a negation flag is found, and the negated argument was used, it functions exactly like a override that is already supported.
Functionally the following two examples are equivilant:
New proposal:
Concerns
There are two primary concerns with this approach.
Flags that already contian "no"
A flag which already starts with
no
such as--no-ignore
would end up getting a doubleno
in the form of--no-no-ignore
. This actually makes sense and is consistent, but looks strange at first glance. An alternative would be to check if a flag starts withno
and simply remove theno
, i.e.--no-ignore
becomes--ignore
but this has the downside of additional processing at runtime, becomes slightly more confusing, and has a higher chance of a conflict.Conflicting names
If a user has selected to auto-generate a negation flag, and the negating flag long conflicts with a flag already in use, a
panic!
will occur. Example,--ignore
and--no-ignore
is already defined elsewhere, and the user has selected to automaticlly generate negation flags, this will cause--ignore
to generate a--no-ignore
flag which already exists causing apanic!
. The fix is to either not use a sweeping setting that applies ot all flags indescriminantly, or to change/remove the already defined--no-ignore
flag.Progress
AppSettings::GenerateNegationFlags
which does the above, but automatically for all flags.AppSettings:GenerateHiddenNegationFlags
which hides all these negation flags.See the discussion in BurntSushi/ripgrep#196
Relates to #748
Edit: Removed
Arg::overridable(bool)
because this can already be done manually by making another flag.The text was updated successfully, but these errors were encountered: