Arguments with default values conflict even if not used

[kornelski]

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

extern crate clap;
use clap::*;

fn main() {
  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"
    ]);
}

I'd expect all of prog --exclusive, prog --default and prog (no args, meaning the default is used) to be allowed.

[kbknapp]

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");
}

[kbknapp]

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.

[kornelski]

I'm using .default_value() in order to have this value printed in the help screen. I could put that info in my help text and handle defaults myself, but that's a workaround.

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.

[kbknapp]

[...] 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:

• A default value is an argument that is always used, only the user is allowed to manually override the value.
• A conflict says, if this particular argument is used, throw and error.

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.

[kornelski]

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 --json option that conflicts with everything else.

[kbknapp]

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 😉

[kornelski]

Thank you! :)

[0ndorio]

@kornelski / @kbknapp
Seems like the issue is still present :/ Any chance to resurrect it?

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 conflicts_with option to the the same argument, which also uses the default option. This should result in the same behavior but instead results in an error as soon as -f or --flag is passed.

Known Workaround: Split default and conflicts_with between the two arguments.

[Dylan-DPC-zz]

@0ndorio can you test if the issue persists on master branch? If yes then I recommend creating a new issue for visibility

[0ndorio]

This is issue is still present on the latest state of the master branch.