-
Notifications
You must be signed in to change notification settings - Fork 420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grouping arguments with arg groups and getting unexpected behaviour #1815
Comments
Interesting, yes, I see the problem.
This error is trying to say that only one combination of Let's see, what can we do? One idea (which is a bit of a hack) is to capture a List of GroupA instance in CmdTest, as follows:
Now, for the following input:
... I get this output:
Then, in your application logic, you can do custom validation and throw a ParameterException, which will show a nicer error message. |
But I agree that this is not very nice. The issue is really, that groups are not just cosmetic, even if your intention is to only use groups for the Option Sections in the usage help... They do interfere with the normal validation, so if options are specified multiple times, the single option validation does not work. (And group validation, if enabled with I need to think about this more... |
Ok :) I did get kind of lost with the long error message, but got the rough gist, just not sure that I'd show that to a user ideally... One option was also that we think about going in a different way to get our usage categories and avoiding using the groups altogether... I'll have a play tomorrow with what you're suggesting and also look forward to your further thoughts :) |
I have to dig a bit, but potentially something like a label on a mixin would let us accomplish documentation wtihout actually having the arg group logic... |
Away from my PC now, but the |
Using a custom renderer for the options section worked perfectly and was much simpler than I expected: Consensys/teku#6556 I'd say this issue could either be closed or turned into a feature request to have built in support for a |
@ajsutton thanks for the feedback! 😅 |
I will update the documentation to make a note that setting At this time the best workaround is making the field holding the group a collection, and doing custom validation to ensure that this collection holds only a single element.
|
I added this section to the user manual: https://picocli.info/#_validation_trade_offs Thank you again for raising this! |
In teku, we're using arg groups to basically categorise command line args into sections to help produce better help information etc...
We have a bunch of overrides etc that are outside of one issue we're having, basically someone has specified the same flag twice, and then, seemingly randomly, an argument is not read from the cli. Consensys/teku#6146
To replicate what we're seeing, I've created a simple project:
User runs
cmdTest --a-str=asdf --b-bool=true --a-bool=true
and everything gets set as expected.If the user runs
cmdTest --a-str=asdf --b-bool=true --a-bool=true --a-bool=true
, then the string in the first group is no longer set.Removing
validate=false
, and replacing withexclusive=false
, we get a complicated error about the group interactions and what is valid / not valid.My guess is that the interaction of the string ending up being null is to do with something that is a side effect of
validate=false
.Printing out help looks like:
which is good, we get groupings etc, and all of the help information is well formatted.
It's definitely possible that we're doing something that the library is really not intended for... It's arguably a 'user error' specifying the same argument twice on the CLI, I'm just not exactly sure how I should approach resolving this kind of issue...
The text was updated successfully, but these errors were encountered: