Open epage opened 2 years ago
Comment by pksunkara Wednesday May 06, 2020 at 15:11 GMT
I think this can be achieved by the hooks proposal mentioned in #1471.
Comment by fbecart Thursday May 07, 2020 at 06:55 GMT
Thanks @pksunkara for looking into it. I see how https://github.com/clap-rs/clap/issues/1471 is related, as it suggests to have a closure returning the default value of an argument.
This issue remains unique in the following ways:
Comment by pksunkara Thursday May 07, 2020 at 12:24 GMT
It is related because we can extend the hook proposal to allow defining possible values too. Prompts is a tangential issue.
Auto completion will probably be tied into the dynamic completion issue.
Comment by fbecart Friday May 08, 2020 at 20:27 GMT
To illustrate the issue, here's a link to the project I'm working on: https://github.com/fbecart/zinoma/blob/9d2ea034d566a92a7464a7ca58c0b75cb87d7072/src/main.rs#L32-L37
Comment by fbecart Wednesday Aug 05, 2020 at 17:19 GMT
Closely related to https://github.com/clap-rs/clap/issues/1232, if not duplicate.
Issue by fbecart Wednesday May 06, 2020 at 12:31 GMT Originally opened as https://github.com/clap-rs/clap/issues/1910
I would like to be able to compute the possible values of an argument dynamically, based on the values provided for some other argument(s).
Use case
I'm working on a CLI which has a goal similar to
make
.The file lists the available targets. Given a value of
FILE
, I am able to load a list of available target names. I would like to use that list as the possible values fortarget
.This would affect the validation of
target
. Ideally, this would also affect its autocompletion.Currently,
possible_values
is expected to be provided as an array slice (&[&str]
) as theApp
is being built. https://github.com/clap-rs/clap/blob/9d03c8497ce17486e31b19fecbe5bec97ac82d09/src/build/arg/mod.rs#L1712 At that time, the value ofFILE
is not available yet.Wanted solution
I would like instead to be able to provide a closure that would compute the possible values for my argument. This closure would take the values of the other app arguments as a parameter.
Workaround
It is already possible to obtain this behavior by parsing the arguments twice (the second time with refined validation):
However, this workaround doubles the overhead of parsing arguments. Also, this solution does not cover the autocompletion part.
Related issues