Write a test that global parsing doesn't conflict with local parsing

[chshersh]

Similar to #56

People shouldn't specify options that conflict with ours. But if they still do, it would be nice to know whether their parsing conflicts with ours. So I propose to add two tests and document their results in public API:

• [ ] my-program --no-input when the custom parser specifies --no-input as well (ideally this should be checked by #13)
• [ ] my-program --no-input my-command --no-input is confusing but ideally should be parsed and return different results for different --no-input. If not, having a test is still good and documenting this behaviour is nice.

[zetkez]

Hi, i want to take this one as my first task. I found a breaking case that is when the custom parser defines --no-input [TARGET] while being a mandatory option. Defined like this the app always displays the help/error message "expected: ...". I assume this is the second case of the listing above. Should i still assume this as the wanted behavior? And does it make sense to add the tests before #67 as i would define custom CliEnvSettings with a custom parser?

[chshersh]

@zetkez Feel free to give it a go! All CLI tests can be found in this module (and can be added here for now):

• https://github.com/chshersh/iris/blob/main/test/Test/Iris/Cli.hs

I believe, it makes sense to test several combinations:

• --no-input as an on-off flag
• --no-input=[SOME_VALUE] as a flag that expects a value
• my-command --no-input: when a custom command expects the same flag

Once we have these 3 test cases, we can improve the documentation to reflect this behaviour 🙂 The point of this issue is not to fix the behaviour but to discover what is the actual existing behavior and document it for our users.

Hope that helps!