Skip to content
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

Get which arg of mutually exclusive ArgGroup was passed #2317

Closed
2 tasks done
Qyriad opened this issue Jan 28, 2021 · 8 comments · Fixed by #4072
Closed
2 tasks done

Get which arg of mutually exclusive ArgGroup was passed #2317

Qyriad opened this issue Jan 28, 2021 · 8 comments · Fixed by #4072
Labels
A-validators Area: ArgMatches validation logi C-enhancement Category: Raise on the bar on expectations S-waiting-on-mentor Status: Needs elaboration on the details before doing a 'Call for participation'

Comments

@Qyriad
Copy link

Qyriad commented Jan 28, 2021

Make sure you completed the following tasks

Describe your use case

One of the use cases the documentation lists for ArgGroup is to have a set of mutually exclusive arguments (with .multiple(false)), but the only way to get which of those arguments was passed is to call matches.is_present(name) for every argument in that group. It would be really nice if I could just get which argument of a mutually exclusive argument group was passed. Currently, to do this you have to check each argument individually, doing something like:

let directions = &["left", "right", "forward"];

let matches = App::new("ArgGroup test")
    .arg(Arg::with_name("left")
        .short("-l")
        .long("--left"))
    .arg(Arg::with_name("right")
        .short("-r")
        .long("--right"))
    .arg(Arg::with_name("forward")
        .short("-f")
        .long("--forward"))
    .group(ArgGroup::with_name("direction")
        .required(true)
        .multiple(false)
        .args(directions))
    .get_matches();

let mut passed_direction = None;
for direction in directions {
    if matches.is_present(direction) {
        passed_direction = Some(direction);
    }
}
let passed_direction = passed_direction.unwrap();

Which is kind of tedious, and not very clean.

Describe the solution you'd like

Being able to write something like:

let matches = App::new("ArgGroup test")
    .arg(Arg::with_name("left")
        .short("-l")
        .long("--left"))
    .arg(Arg::with_name("right")
        .short("-r")
        .long("--right"))
    .arg(Arg::with_name("forward")
        .short("-f")
        .long("--forward"))
    .group(ArgGroup::with_name("direction")
        .required(true)
        .multiple(false)
        .args(&["left", "right", "forward"]))
    .get_matches();

let passed_direction = matches.value_of("direction");

would be really nice. value_of() is just an example, there — I'm not particular about the exact API is to get this 🙂

@ldm0
Copy link
Member

ldm0 commented Jan 29, 2021

I think conflicts_with_all might matches your use case.

@pksunkara
Copy link
Member

But that's not the thing he is asking for.

@Qyriad
Copy link
Author

Qyriad commented Jan 29, 2021

she*, but I believe you're correct. ArgGroup::multiple() already sets the mutual exclusivity. I'm looking for a way to get which argument in an ArgGroup was passed, from an ArgMatches. I don't see how conflicts_with_all() helps me there.

@ldm0
Copy link
Member

ldm0 commented Jan 30, 2021

Sorry for disturbing, haven't slept much yesterday and my mind isn't clear.

So we need to design a new api specifically for fetching the triggered argument and also the value? @pksunkara .

@pksunkara
Copy link
Member

Yes, but this is not a priority for 3.0

@pksunkara pksunkara added this to the 3.1 milestone Jan 30, 2021
@Qyriad
Copy link
Author

Qyriad commented Jan 30, 2021

So we need to design a new api specifically for fetching the triggered argument and also the value?

Ideally, though I would also be fine with an API just for fetching the triggered argument — which would mean that getting the value of that argument would be a separate step.

@DocKDE
Copy link

DocKDE commented Oct 26, 2021

I'd like this as well but I'll be patient :)

@epage epage added A-builder Area: Builder API A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations A-validators Area: ArgMatches validation logi and removed C: arg groups A-builder Area: Builder API A-parsing Area: Parser's logic and needs it changed somehow. labels Dec 8, 2021
@epage epage removed this from the 3.1 milestone Dec 13, 2021
@epage epage added S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing S-waiting-on-mentor Status: Needs elaboration on the details before doing a 'Call for participation' and removed S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing labels Dec 13, 2021
@epage
Copy link
Member

epage commented May 25, 2022

Currently, when we parse an argument and store its value in ArgMatches, we also store that value under the ArgGroup's name,, as was previously mentioned.

With #3732, we've changed some things related to storing the value which is having me re-think it. In #3405, we are looking at defining actions to allow users to describe how a value should be written to the ArgMatches. #3748 is considering doing the same for arg groups which could include writing out which argument in an arg group was active. This doesn't let you access both the name and value but, as was mentioned, the user can look up the value.

epage added a commit to epage/clap that referenced this issue Aug 12, 2022
Now that `Id` is public, we can have `ArgMatches` report them.  If we
have to choose one behavior, this is more universal.  The user can still
look up the values, this works with groups whose args have different
types, and this allows people to make decisions off of it when otherwise
there isn't enogh information.

Fixes clap-rs#2317
Fixes clap-rs#3748
epage added a commit to epage/clap that referenced this issue Aug 12, 2022
Now that `Id` is public, we can have `ArgMatches` report them.  If we
have to choose one behavior, this is more universal.  The user can still
look up the values, this works with groups whose args have different
types, and this allows people to make decisions off of it when otherwise
there isn't enogh information.

Fixes clap-rs#2317
Fixes clap-rs#3748
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-validators Area: ArgMatches validation logi C-enhancement Category: Raise on the bar on expectations S-waiting-on-mentor Status: Needs elaboration on the details before doing a 'Call for participation'
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants