IsUsageRequested is not true for missing mandatory subcommand args

[haf]

Description

E.g.

type RMode = R1 | R2
type RouterArgs =   | [<Mandatory>] Listener of routerMode:RMode
type Args = | [<CliPrefix(CliPrefix.None)>] Router of args:ParseResults<RouterArgs>
let parser = ArgumentParser.Create<Args>(programName = "rutta.exe", helpTextMessage = "repro")
let parsed = parser.Parse([| "Router" |], ignoreUnrecognized=true, raiseOnUsage=false)
parsed.IsUsageRequested  // => false, but should be true, because Router is missing a Listener.

[haf]

https://github.com/logary/logary/pull/387/commits/57c1374afee16f8119f8430c9594855c48473cc6

Inside dir src/services/Logary.Services.Rutta (se commit message)

[haf]

Has this been fixed with any of the releases in the last two years?

[eiriktsarpalis]

Probably not, at least it hasn't been addressed intentionally.

[haf]

Ok, no worries, there's a workaround available. I saw the docs had been updated about subcommand parsing, that's why I asked. Thanks for the reply.

[bartelink]

There's a good release pipeline and active maintainers if you (or anyone) wanted to take a run at it now...

[fpellet]

IsUsageRequested is currently only true if help is requested, not in the event of an error. So the case reported seems to be a change in behaviour. Nevertheless, the mandatory field will raise an exception with the parse arguments used in the initial message with #221 . This may meet haf's need.

[bartelink]

Atm IsUsageRequested seems do exactly what it purports to - convey whether the --help option (or configured custom equivalents) has been explicitly specified.

I'm not averse to an alteration/clarification to how this should work overall, but in general I'd expect there to be APIs to verify missing arguments either via a property or ArguParseException, with the caller mapping that to printing of help as desired (i.e. while --help should definitely trigger a help message, I can imagine people wanting to be selective about whether to do that in the case of arguments being missing; having the 'help requested' and 'help might make sense because there's missing arguments' aspects be separated seems to be clearest approach, but I may well be missing a very obvious and clean answer).

Closing for now - if anyone wants to propose a set of tests and API changes to represent the overall semantics, the build pipeline is now in a good place to get it released the minute we have a clear proposal as to how it should work.