These are chat archives for kbknapp/clap-rs

25th
Dec 2017
sbstp
@sbstp
Dec 25 2017 00:02
some other codecs might not have a bitrate argument
Kevin K.
@kbknapp
Dec 25 2017 00:18
Ah ok, in that instance it's probably be best to have the value of nitrate unbounded, but if some codecs require a nitrate and others don't you can use Arg::required_if](https://docs.rs/clap/2.29.0/clap/struct.Arg.html#method.required_if)
I'm on mobile so my formatting is all messed up :P
Then in your code you just validate that the nitrate matches whatever would be valid for that codec
There are other things you can do like make bitrate conflict with certain codecs conditionally (if for example some code s shouldn't have a bitrate) or have conditional default bitrates based on the codec value
All those are on the docs.rs site under the Arg methods, typically ending in _if or _ifs for multiple conditions
sbstp
@sbstp
Dec 25 2017 00:44
I did see the required_if function, but the arguments aren't required. They're optional and depend on the codec. A way of of phrasing it would be "bitrate" is only valid if "codec" == "opus", some sort of valid_if method.
Kevin K.
@kbknapp
Dec 25 2017 00:52
Currently there isn't a way to say x codec allows 1,2, or 3 bitrates but y codec only allows 4, 5, or 6 codec. Only to say codec x required a nitrate but codec y doesn't (or to say the default bitrate is different between the t
The codecs)
You'd have to do that in user code
Which is totally possible, just not built in to clap
sbstp
@sbstp
Dec 25 2017 00:54
that's why I wanted to do a two pass parsing
Kevin K.
@kbknapp
Dec 25 2017 00:55
Ah ok I understand
Do you have any positional values defined?
sbstp
@sbstp
Dec 25 2017 00:57
all the flags would have a name, so no
I can do aconv -c opus -- --bitrate 64000
but I must use the -- to separate them
Kevin K.
@kbknapp
Dec 25 2017 00:58
So adding possible_values_if is totally possible if you want to file an issue, but it's not implemented yet. And due to holidays I wouldn't be able to implement it for another week or so
You can probably add TrailingVarArg to remove the --
But that still requires --bitrate to be last
Which is suboptimal
sbstp
@sbstp
Dec 25 2017 01:00
I'll open an issue but we can work on it after the holidays
adding an extra -- is not a blocker
Kevin K.
@kbknapp
Dec 25 2017 01:00
You could define a positional value and add Arg::allow_hyphen_values and multiple(true)
Which could work but is still tacky
sbstp
@sbstp
Dec 25 2017 01:01
I think that's what my gist does
Kevin K.
@kbknapp
Dec 25 2017 01:01
:+1:
Ah yep, sorry I hadn't opened it yet, just saw it
You could also play with Arg::last which might help, but still suboptimal
sbstp
@sbstp
Dec 25 2017 01:04
thanks for the help, to be continued later!
Kevin K.
@kbknapp
Dec 25 2017 01:06
The most simple thing in the mean time would be to allow --bitrate to be unbounded then in user code before anything else check --codec and make sure the values between the two are acceptable and error if not
Using ansi_term you can even make the error appear as if it came from clap