-
-
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
Arguments with default values conflict even if not used #1071
Comments
Default values are provided regardless of whether or not an argument was used, so it's as if the arguments are always used. Perhaps what your looking for is conditional default values? What you're wanting can be accomplished in user code pretty easily as well. extern crate clap;
use clap::*;
fn main() {
let matches = App::new("prog")
.arg(Arg::with_name("default")
.takes_value(true))
//.default_value("default"))
.arg(Arg::with_name("exclusive")
.long("exclusive")
.conflicts_with("default"))
.get_matches_from(vec![
"prog", "--exclusive"
]);
let default = matches.value_of("default").unwrap_or("default_value");
} |
Technically speaking it's possible for clap to know if it was a default value or not that was used and simply ignore conflicts if so...but I'd need to hear more arguments for it. |
I'm using I presume from implementation perspective the current behavior is more straightforward, but from user perspective I don't see any argument in favor of it, since a set of flags configured in a way that never works is of no use. |
I understand that, but I'm more wondering if there is a better way to solve this issue than adding additional logic in clap. (Note: I'm not insulting your intelligence here because I know you're quite familiar with this project, but just to make sure we're on the same page 😄) In clap speak:
I understand that in your case, the conflict should only arise if the user overrides that default value, however that's now how clap is structured at the moment as those two statements are incompatible. What I meant by "arguments for it" is I haven't had anyone yet talk to me about wanting to conflict with a arg which provides a default value so I'm unsure how common the case is. Are you modeling after a well known CLI that provides some precedence? It's required to add this feature, I'm just curious 😉 I don't know the specifics of the CLI you're designing so it's hard for me to make any suggestions. |
My specific case is a CLI that can either be used by specifying arguments individually, or by specifying a JSON file that specifies all of them. So I have a bunch of options, and a |
Makes sense to me. I think this is fairly easily classified as a bug the more I play with it. Thanks for taking the time to file this and hash it out with me 😉 |
Thank you! :) |
@kornelski / @kbknapp This playground contains a slightly modified version of the test case introduced in f7a6955. The main difference to the original is that I moved the Known Workaround: Split |
@0ndorio can you test if the issue persists on master branch? If yes then I recommend creating a new issue for visibility |
This is issue is still present on the latest state of the |
Expected Behavior Summary
I expect conflicts to happen only when conflicting arguments are explicitly present on the command line.
Actual Behavior Summary
It's enough for an argument to have a
default_value
configured to cause a conflict.Sample Code or Link to Sample Code
I'd expect all of
prog --exclusive
,prog --default
andprog
(no args, meaning the default is used) to be allowed.The text was updated successfully, but these errors were encountered: