-
|
I'm looking at the completions-derive example, and it only works because all (other) options are What's the most natural way to handle this? So far the best I could come up with is: https://github.com/rustshop/rustshop/blob/931dbb87df2826ab6a480bf5096d91527cc98f4f/infra/utils/aws-bootstrap/src/opts.rs#L93 . I basically handle completions as another version of command line options, and then also include them in the main one by flattening. A bit meh, but kind of works. What I'd really want is to have just two calling conventions: one normal, one for completions: I tried to do it with an |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
I'm a bit confused as to how this is helping. The core issue is that you have required arguments which are mutually exclusive with e.g. changing /// AWS profile to use when calling `aws` CLI
#[clap(long = "region", env = "AWS_REGION")]
pub region: String,to /// AWS profile to use when calling `aws` CLI
#[clap(long = "region", required = true, env = "AWS_REGION")]
pub region: Option<String>,We do have some brainstorming to improve this, like in #2621. |
Beta Was this translation helpful? Give feedback.
-
|
#3926 brought up the idea of an env variable to activate completions |
Beta Was this translation helpful? Give feedback.
I'm a bit confused as to how this is helping.
The core issue is that you have required arguments which are mutually exclusive with
--completions. With the builder API, you'd useexclusive(true)on the completions argument and be done. With the derive API, the problem is that the derive has nothing to populate the required arguments with. A workaround is to make themOptionbut setrequired = true. This will make it so they will only beNonewhen--completionsis set.e.g. changing
/// AWS profile to use when calling `aws` CLI