dispatchGen should have an option to forward the result "as is" about cligen

[c-blake]

Yeah. Something like this occurred to me when I was adding echoResult.

Maybe returnResult is a better name? That's what the dispatchFoo will be doing, after all. forwardResult makes me think the result would be sent to another proc or something.

It make senses to raise a compile-time error if both echoResult and returnResult are true. I'm not sure more error checking than that is really needed. So, just to be concrete I am thinking:

dispatchGen(foo, returnResult=true)
let x = dispatchFoo()
# User can now do whatever they want with x
# E.g. `echo x; quit(0)` recapitulates echoResult=true.

Of course, one could also put some cmdLine synthesized from whatever sources into the dispatchFoo() call. Anyway, I think this is pretty easy.

[c-blake]

There could be some weirdness in what to do if the user or other sources of cmdline contain --help or --version, though. In the current generated dispatcher, this just stops all parameter parsing and exits. Because the default value for an int is 0, this is translated to a zero exit status and all is right in the world as --help and --version requests are not errors.

[c-blake]

This last comment is really a question about how/what should be communicated to the dispatchFoo() caller when there is a --help in there. Should we raise an exception forcing them to call in a try/except block? That feels a little awkward, but I'm not sure there is a better alternative. We could just return the default initialization value for whatever the return type is, but what if that is a valid value in a non-abortive parameter parsing context -- and also the caller would have to check it anyway with an if/else that is about as much work as a try/except? We probably don't want to quit(0)..Or maybe we do? Anyway, there are a few choices here. I'd be interested in what you propose.

If you agree that the exception pathway is best, what would make sense to me is to lift the help and version exception types into "cligen actual" (to adapt a U.S. military terminology) from their current local scope and export them. Then we could just have dispatch do the try/except currently at the very bottom of dispatchGen in the big quote do: block. Well, really since the quit(dispatchFoo()) changes in both dispatch and dispatchMulti we might want to replace those quit calls with something like a proc that does the try/except/quit. I think it can be just a proc taking an int and returning void, like quit itself, also part of and exported by cligen actual.

All manual calling of the generated dispatcher would be impacted, but I doubt that is common out there in the wild among my (mostly silent) users. So, I don't see backward compatibility as a major hurdle here.

[timotheecour]

oh just saw all ur comments
if you're on gitter it may be easier; btw I'm working on a PR for this right now, which exposed a weird bug nim-lang/Nim#9656 (but I found a workaround) ;

let me think about what u said regarding handling help/version (+ what to do on parsing error)

[c-blake]

Eh...github is fine. Only a 1 hour latency. I think I covered most of the gotchas. There's still some work to get callWrapped/that main try/except to work in this new mode. I was going to do it tomorrow/over the weekend if you didn't, but I thought I'd solicit interface feedback.

[c-blake]

You've probably seen this already, but just in case..Looking at it a little more, we probably would need to add some ParseError exception to be raised both inside parser() instead of exitCode manipulations and also to raise instead of the quit(1) for missing mandatory parameters. Then our new invoker() proc to replace quit can distinguish error exits from non-error exits.

This is a pretty involved change, but seems theoretically possible without much impact on users (none if they do not call dispatchFoo directly - those who do will immediately see exceptions they need to handle and look into why which will be in RELEASE-NOTES.md).

[c-blake]

Having tried to do this and not gotten very far before running into Nim meta-limits, you might find the diff for how I did it helpful. It's pretty close to what I described (I had some think-O about an invoker replacement for quit at the call sites...That was never going to work - sorry for the misdirect if it mattered). We just do the try/except at the inside-cligen-call sites. For your usage/call sites you might look at test/ResultInt.nim and/or RELEASE_NOTES.md for guidance.

For what it's worth, I think addressing #44 might be a bit easier now. It doesn't seem hard to add some code to grab other run-time sources of command parameters (environment vars and/or config files) and merge them with whatever a CLI user passes before hand off to a dispatchFoo(cmdLine=). It's at least certainly easier to do manually (which you might need to do in order to correct the "hierarchicality mismatch" of flat e.vars and structured cf files I mentioned in that issue).

Also, of course, let me know if I created any problems I didn't notice in my own testing.

[c-blake]

Also, to follow up on this and 4a8c262#commitcomment-31244947 ,
I considered using some kind of Option[T] result, but then callers still need a bunch of "did it work or not" checking that is at least as much as hassle as the try/except.

Also, I could be convinced that two exception types is overkill and that some NonCallOkExit exception could replace the pair of HelpOnly, VersionOnly (and any other thing that comes along), but we probably want at least ParserError and NonCallOkExit to be distinct.

I was thinking the CLI author might want to separate out HelpOnly and VersionOnly control flow with some special logic of some kind. That still seems possibly useful, and the names are a bit more self-explanatory and catching two exception types is easy in Nim.