Discussion: allow multiple subcommands as argument
See original GitHub issue(disclaimer, I have very limited experience with / knowledge of this library, my apologies in advance).
You can do this:
command --intFlag 1 --stringFlag a --anotherIntFlag 2
And this works fine for simple cases. However, what if I have a complex cli structure, where you always need to provide a lot of options.
command --param1IntFlag 1 --param1StringFlag a --param1AnotherIntFlag 2 --param2IntFlag 1 --param2StringFlag a --param2AnotherIntFlag 2 --param3IntFlag 1 --param3StringFlag a --param3AnotherIntFlag 2 and so on for 10-20 parameters...
Rather verbose. The problem is of course the need for grouping per param, while the multi-values differ in type. Now if I’m understanding correctly, it’s not possible to do the following:
command --param1 1 a 2 --param2 1 a 2 --param3 1 a 2
That’s because for multi-value parameters, the value types should be the same and here we are mixing ints and strings. That is unless I define a custom type for each param that converts the combination of values. I’m I correct so far?
To work around this, I am actually working with multiple same-level subcommands to achieve this (since with commands, the individual values are converted rather than as a multi-value set):
command param1 1 a 2 param2 1 a 2 param3 1 a 2
This is possible, because I made every command a sub command of every other sub command, but this produces a rather complex command tree. What would make it a lot easier is if I could instruct picocli to allow for multiple sub commands on the same level, so that it would match any command on any level, prioritizing nested matches first (so A-with-sub-B B gets matched over A-with-sub-C B).
Thoughts? Can I solve this a better way already perhaps? I would be very happy to hear this is already possible in a clean way.
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (10 by maintainers)
Picocli 4.0.0-alpha-1 has been released which includes support for repeating composite groups. See https://picocli.info/#_argument_groups for details.
I believe this should should meet the requirements of the original use case.
Please try this and provide feedback. We can still make changes.
What do you think of the annotations API? What about the programmatic API? Does it work as expected? Are the input validation error messages correct and clear? Is the documentation clear and complete? Anything you want to change or improve? Any other feedback?
Update: I will try to include a fix for #358 in the upcoming 3.6 release.