Skip to content
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

[Feature Request] Option dependencies #295

Closed
jusw85 opened this issue Mar 6, 2018 · 6 comments
Closed

[Feature Request] Option dependencies #295

jusw85 opened this issue Mar 6, 2018 · 6 comments

Comments

@jusw85
Copy link

jusw85 commented Mar 6, 2018

Would be nice to specify option dependencies i.e. if an option is present, another option must also be present.

Reference example ('requires' flag):
https://github.com/kbknapp/clap-rs/blob/master/examples/07_option_args.rs
https://docs.rs/clap/2.31.1/clap/struct.Arg.html#method.requires

Usage example:

# ./pointorline --start=5,5 # start can exist by itself
# ./pointorline --end=10,10 # end cannot exist without start, error!

Right now it's possible to check this after parsing is done, so it's not a pressing issue, but it would be nice to have.

@remkop
Copy link
Owner

remkop commented Mar 7, 2018

Ok, interesting!
There are other tickets I want to work on first but if anyone submits a pull request with unit tests I have no objection to supporting this functionality.

@lenkite
Copy link

lenkite commented Apr 27, 2018

It would be great to also have some way of specifying option alternatives. Like in the below -u, -p, -c are only required if -P is not present.

list-nodes -c <controlHost> -u <user> -p <pass>  OR list-nodes -P <profileName>

(PS: @rempkop Thank you for making this great library. Its delicious !)

@remkop
Copy link
Owner

remkop commented Apr 27, 2018

Related: #199 will give support for mutually exclusive options. Currently I don’t think that ticket mentioned making a single option exclusive with a group of options. It may be good to make a note of this idea on the #199 ticket.

What may be interesting for your use case is that picocli already allows you to specify a custom synopsis to show which options are mutually exclusive: http://picocli.info/#_custom_synopsis

@lenkite
Copy link

lenkite commented Apr 28, 2018

Thanks for the advice. I have added a note to the #199 ticket. For now, I will add a custom synopsis as you suggest.

@remkop remkop added this to the 3.1 milestone May 16, 2018
@remkop remkop modified the milestones: 3.2, 3.3 Jul 6, 2018
@remkop remkop modified the milestones: 3.4, 3.5 Jul 23, 2018
@remkop remkop modified the milestones: 3.5, 3.6 Aug 3, 2018
@remkop remkop modified the milestones: 3.6, 3.7 Aug 26, 2018
@remkop remkop modified the milestones: 3.7, 3.8 Oct 19, 2018
@remkop remkop modified the milestones: 4.1, 4.0 Nov 10, 2018
NicolasMassart added a commit to NicolasMassart/pantheon that referenced this issue Jan 28, 2019
…options

This mechanism is aimed at preventing the use of options if the associated
service is disabled. This is not a generic system as our need is simple here.
But in future version of PicoCLI some options dependency mechanism may be
implemented that could replace this.
See remkop/picocli#295
Our current mechanism apply to p2p, rpc (http+ws), mining, privacy and metrics.

Also renamed inconsistent isRpcHttpEnabled option variable and moved
--privacy-enabled option to be on top of other privacy options.

Related tests where added or updated and renamed.
NicolasMassart added a commit to PegaSysEng/pantheon that referenced this issue Jan 29, 2019
fixes NC-1737 by adding an option dependency mechanism for "enabled" options

This mechanism is aimed at preventing the use of options if the associated
service is disabled. This is not a generic system as our need is simple here.
But in future version of PicoCLI some options dependency mechanism may be
implemented that could replace this.
See remkop/picocli#295
Our current mechanism apply to p2p, rpc (http+ws), mining, privacy and metrics.
It logs a warning wherever some options are used that require another one to be enabled.

Also renamed inconsistent isRpcHttpEnabled option variable and moved
--privacy-enabled option to be on top of other privacy options.

injects a Logger in PantheonCommand constructor to log and also provides injection capabilities for a mock in tests.
adds unit tests
updates tests logger name to TEST_LOGGER to prevent confusion with the mock

remove --max-trailing-peers after merge with master where it was deleted

updated rules for metrics
@remkop
Copy link
Owner

remkop commented Feb 13, 2019

This is a cross-post from #199. Future updates will be on the #199 ticket, so please check there for updates.

A first cut of support for ArgGroups has landed in master. This adds support for:

  • mutually exclusive options and positional parameters (exclusive = true)
  • co-occurring options and positional parameters (exclusive = false: require all elements in the group, or none)
  • composite groups
  • groups can be required or optional

Example:

 @Command(argGroups = {
         @ArgGroup(name = "EXCL",      exclusive = true,  required = true),
         @ArgGroup(name = "ALL",       exclusive = false, required = true),
         @ArgGroup(name = "COMPOSITE", exclusive = false, required = false,
                   subgroups = {"ALL", "EXCL"}),
 })
 class App {
     @Option(names = "-x", groups = "EXCL") boolean x;
     @Option(names = "-y", groups = "EXCL") boolean y;
     @Option(names = "-a", groups = "ALL") boolean a;
     @Option(names = "-b", groups = "ALL") boolean b;
 }

This defines a composite group with the following synopsis:

[(-x | -y) (-a -b)]

The composite group consists of the required exclusive group (-x | -y) and the required co-occurring group (-a -b).

Valid user input for this group would be:

  • no options at all (because the composite group itself is non-required)
  • -x -a -b (in any order)
  • -y -a -b (in any order)

Any other combination of -x, -y, -a and -b would give a validation error.


Still TODO:

  • show group synopsis in usage help message
  • show group headings in options list
  • update annotation processor in picocli-codegen to build a model from the new annotations at compile time
  • documentation in user manual and release notes

That said, the majority of the functionality is there.
I would appreciate it if people would try this to see if it meets their requirements and to find any places where the API should be improved.

remkop added a commit that referenced this issue Mar 18, 2019
* mutually exclusive options (#199)
* option that must co-occur (#295)
* option grouping in the usage help message (#450)
* repeating composite arguments (#358 and #635) (this should also cover the use cases presented in #454 and #434 requests for repeatable subcommands)
remkop added a commit that referenced this issue Mar 18, 2019
remkop added a commit that referenced this issue Mar 18, 2019
] options that must co-occur (dependent options)
@remkop remkop modified the milestones: 4.0, 4.0-alpha-1 Mar 30, 2019
@remkop
Copy link
Owner

remkop commented Mar 30, 2019

Picocli 4.0.0-alpha-1 has been released which includes support for options that must co-occur (dependent options).
See https://picocli.info/#_argument_groups for details.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants