Make arg enabled depending on value of other arg?

[matthiasbeyer]

I have a ValueEnum like this:

enum Foo {
    A,
    B,
    C,
}

I want to make another argument in my CLI valid only if B is specified:

// ...
struct CLI {
    #[clap(short, value_enum, default_values_t = [Foo::A])]
    foo: Foo,

    #[clap(short, only_possible_to_specify_if("foo", Foo::B))]
    bar: PathBuf,
}

Note that bar is not required though! But it is invalid if Foo::A or Foo:C are specified.

How would I do this?

[epage]

We currently have two facilities

• required_if_eq. The current argument becomes required if another argument equals a value
• requires_if: The other argument becomes required if the current argument equals a value
• required_unless_present: The current argument is required unless the other argument is present

but what you need is "the other argument's value is required to be XX if the current argument is present"

Without a high demand for it, I'm not thrilled with adding yet another argument relationship type until we generalize argument relations

As a workaround, you can catch this yourself and use clap to create the error message.

[sjwo]

I have a similar question; let me know if this should be a separate discussion instead of a comment here.

Is there a way to enable or disable one or more arguments based on out-of-band logic that's evaluated partway through Clap parsing?

In particular, is is possible to enable or disable certain arguments based on a value that is read from a file, whose filename was specified in previous argument? I am currently trying to figure out how to do this in the Derive interface, although am wondering if the Builder interface would be necessary.

My use case is that I'm writing a multi-domain problem solver, and each domain has zero or more different configuration options. A problem instance is stored in its own file, and is specific to some domain, but not to that domain's configuration: instead, the user of the solver gets to configure the domain.

Since filename of problem instance file is passed to the solver as a command line argument, and since the appropriate domain name is listed in each problem instance file, I'd like to just read the domain name from the problem instance file, instead of making the user specify the problem domain as a command line argument. Then, depending on what the domain is, I'd like to require a different set of additional domain-specific command line arguments.

For example, if the sandwich domain needs type of bread and open or closed specified, while the icecream domain needs cone or cup specified, then for the problem1 file with the first line

domain sandwich

and the problem2 file with the first line

domain icecream

...I'd like the argument requirements to follow these examples respectively:

make_food problem1 wholewheat closed

and

make_food problem2 cone

The control flow during parsing would be something like this:

1. check that required problem instance filename argument is present;
2. start reading the problem instance from the file specified in (1), and extract the domain name;
3. enable arguments for the domain found in the problem instance file, and disable all other domains' arguments.

I guess this is kind of like selecting a Subcommand, but selecting it based on the contents of a file instead of the value of a command line argument. Alternatively, maybe it is conceptually more like required_if_eq, applied to each domain-specific argument, but again evaluated based on something outside of Clap.

[epage]

No, this is not supported today.

The generalized requirements stuff I mentioned in my other answer would allow you to implement this.

Another potential route is if we allow partially parsing of subcommands (#4395), then you could see what was parsed and adjust from there.

Work arounds:

• You could just allow all arguments and then error in your code
• You could use external subcommands, evaluate, and then parse the subcommand.

[jtmoon79]

I've run into the same need. Just wanted to share my situation, in case it helps @epage .

My problem

I want an argument, file paths (PATHS), to be required but only if there were no file paths passed via stdin. My current clap help looks like

$ s4 --help
Usage: s4 [OPTIONS] <PATHS>...

Arguments:
  <PATHS>...  Path(s) of log files or directories. Paths may also be passed via STDIN one per line

Currently, if I run without PATHS as a CLI argument but do pass arguments via STDIN, clap prints an error message

$ echo /tmp/logfile | s4
error: The following required arguments were not provided:
  <PATHS>...

I cannot do an "out of band" check for the PATHS argument parser. I would like to have this clap argument logic be "is there any data on STDIN? If yes, then the PATHS argument is satisfied. If no, then print the error message about 'required arguments'".

My needed function

Maybe some new function like fn required_if_check(check: &dyn Fn() -> bool). If function check returns true then treat argument as required (and print error message if it was not passed in by the user). If function check returns false then treat the argument as optional.
In other words, an "optional requirement".

Extending this thought further (feature creep): if the function check can have access to the current clap argument set, then users could do their own custom checks on other clap arguments.

My workaround

I will have a special signifier string "-". This string satisfies the required=true for argument PATHS. The program, upon seeing that argument value "-" as a PATHS value, will read STDIN.

$ echo /tmp/logfile | s4 -

btw, recently upgraded to clap v4 and it works great! Thanks for working on this!

[epage]

@jtmoon79

Maybe some new function like fn required_if_check(check: &dyn Fn() -> bool). I
...
Extending this thought further (feature creep):

I think you are starting to move to the idea I mentioned earlier:

The generalized requirements stuff I mentioned in my other answer would allow you to implement this.

which is talked about a bit at #3476

The downside to using it in your use case is you need to read the contents of stdin in your check, which is a mutation, and you need to store it somewhere.

Note that #3476 does talk about custom value sources / fallbacks which could allow for reading stdin but it would have the wrong precedence than what you need. Might be worth commenting on your use case there.

Overall though I feel like this is something that I would implement in post-processing. I would make PATHS optional and then report an error if neither source is present.