New elements in @Option annotation

[kmosakowski]

What do you think of adding new elements into @Option annotation like

String[] depends - List of other options that this option depends on
String[] forbids - List of other options that this options is incompatible with

Those elements are available in the args4j library https://github.com/kohsuke/args4j
Check documentation info -> http://args4j.kohsuke.org/args4j/apidocs/org/kohsuke/args4j/Option.html

[remkop]

I considered that and decided instead to create Argument Groups which is a much more powerful mechanism to accomplish the same and more. This has been available since picocli 4.0, please give it a try!

[kmosakowski]

OK, no problem, I try to be open-minded :D

Would you be so kind as to tell me how I can implement that situation?

My CLI program has 4 options -f -a, -b, -c

Option -c can be used only with -a and -b
Option -f is required

Working examples

program -f
program -f -a -c
program -f -b -c
program -f -a
program -f -b

In documentation is an example where all options like -a, -b and -c must be required, and we can play with multiplicity. But when I set multiplicity 0..1 in all options -a, -b, -c then users could run the program in a wrong way, for example

program -f -c

[remkop]

Yes, ArgumentGroups cannot provide validation for this pattern. This is a documented limitation.

You'll have to do programmatic validation to accomplish this.

[kmosakowski]

The best thing about frameworks is that frameworks do many things for us. That is why I chose picocli. Look for example Spring, a powerful framework, that does itself as many things as can.

Because of that, I would like to somehow convince you to add those flags :) because it would make life easier. Why write validation for flags dependent or forbids other flags if the framework can do it for us :)

Then programmer can focus on business logic or other things