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

Question/Feature request: Any way to do required_ifs "flags exists". #1126

Open
8176135 opened this issue Dec 12, 2017 · 5 comments
Open

Question/Feature request: Any way to do required_ifs "flags exists". #1126

8176135 opened this issue Dec 12, 2017 · 5 comments
Labels
A-validators Area: ArgMatches validation logi C-enhancement Category: Raise on the bar on expectations S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing

Comments

@8176135
Copy link

8176135 commented Dec 12, 2017

Clap version: 2.29.0

I'll start with the problem I am trying to solve:
I have the flags -A, -B, -C, which are all optional by themselves. However, if both -A, and -B are used, -C must also be used. (-C takes some values that -A and -B need)

  • Clap has required_unless_all(name), but doesn't have the opposite of that e.g. required_if_all(name)?

  • I know clap has required_ifs(), but that compares the input from an argument with a value, but the value doesn't matter in this case, only that the flags are present or not.

  • Having requires() on -A and -B also won't work in this case, as only having one of them will make -C required.

  • requires_all() does the opposite of what I want, requiring both -A and -B to be used -C can be used

None of the above is unexpected, (the documentation is really good at explaining each option 👍 ), but there doesn't seem to be a required_if_all([names]). Any ideas?

@kbknapp
Copy link
Member

kbknapp commented Jan 9, 2018

I'm not opposed to adding something like that, however I'll explain why it doesn't exist (yet).

When dealing with flags and requirements, since they are a simple on/off switch, if you know -A and -B requires -C (as the programmer), you could just act as if -C was used. I'd recommend telling the user via a help message or something, ("using -A and -B together implies -C", etc.).

From a UX standpoint, the user isn't supplying any additional information by being forced to pass -C since it's a flag. The only thing they're saying is essentially, "I know the -C switch is required."

The only time requiring an additional flag is a good idea is when the task is destructive (like deleting, etc.) and the user needs to confirm that they're sure they know what they're doing (by including the flag) such as --force usually, or -D in git branch.

However, in these circumstances it's far better to have a custom error message telling the user what is about to happen and why the extra flag is required. A generic clap error of, "-C is required but wasn't used" could actually be harmful here, since the user will almost always just blindly copy the -C argument and not know why.

@kbknapp
Copy link
Member

kbknapp commented Jul 22, 2018

Closing for now to get 3.x out the door. We can re-address after release if needed.

@CreepySkeleton
Copy link
Contributor

I'm leaving it closed for the time being

@pksunkara pksunkara reopened this May 26, 2021
@epage epage added C-enhancement Category: Raise on the bar on expectations A-validators Area: ArgMatches validation logi S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing and removed T: RFC / question labels Dec 8, 2021
@messense
Copy link
Contributor

Is there any way to do "required if other options present"? For example --tls-key <PATH> is only required if --tls-cert <PATH> is present.

@epage
Copy link
Member

epage commented Jan 17, 2022

Interesting. We support "present" for defaults but not requires or required.

#3008 has the potential for making our required, requires, defaults, etc more general.

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-design Status: Waiting on user-facing design to be resolved before implementing
Projects
None yet
Development

No branches or pull requests

6 participants