Help for fallthrough options in subcommands

[gcarcassi]

trafficstars

I am using app.fallthrough() to define common options at the topmost level. While this works perfectly, it seems that the help message does not include those "inherited" options.

For example, see below the output for my tool is currently. What I'd expect is that the general options are repeated for the subcommand as well.

> slate --help
SLATE command line interface
Usage: ./slate [OPTIONS] SUBCOMMAND

Options:
  -h,--help                   Print this help message and exit

General:
  --output TEXT               Output format. Must be default or json.
  --debug                     Prints extra info to debug the commandline.

Subcommands:
  app                         Manage SLATE applications
  version                     Outputs the version of the command-line
  vo                          Manage SLATE vos
  cluster                     Manage SLATE clusters


> slate app --help
Manage SLATE applications
Usage: ./slate app [OPTIONS] SUBCOMMAND

Options:
  -h,--help                   Print this help message and exit
  --vo TEXT (REQUIRED)        The VO for which to install the application
  --cluster TEXT (REQUIRED)   The cluster in which to install the application

Subcommands:
  install                     Install an application
  list                        Lists installed applications
  delete                      Delete an application

Am I missing something?

[henryiii]

I know this has come up previously somewhere; parent lookup if fallthrough is on is currently missing. It should be pretty easy to add to a Formatter (it should be provided in the built-in formatter).

[henryiii]

@lczech asked about this on Gitter, that's why I can't find it in issues.

[gcarcassi]

Thanks for the prompt reply. I'll have a look at the code and try to figure out if this is something I can contribute...

[henryiii]

Feel free to try and ask questions. The additions would probably be in CLI/Formatter.hpp. make_groups would need to check parents if fallthrough is enabled and append to the option list if so (probably recursively on up the parent chain?). (Added #130 to help keep changes out of make_group and only in make_groups).

[gcarcassi]

That's along the lines of what I was able to figure out. More or less replace the app->get_groups() and app->get_options() with something that recursively goes up the parent chain... I'll start by adding them in the Formatter itself, but it may make sense to have them in the App... (like app->get_groups_recursive()). We'll see how long it takes me... :-)

[gcarcassi]

I think it's a bit more complicated. So far I have:

Install an application
Usage: ./slate app install [OPTIONS] app-names

Positionals:
  app-names TEXT REQUIRED     Applications to install

Options:
  -h,--help                   Print this help message and exit
  -h,--help                   Print this help message and exit
  --vo TEXT REQUIRED          The VO for which to install the application
  --cluster TEXT REQUIRED     The cluster in which to install the application
  -h,--help                   Print this help message and exit


General:
  --output TEXT               Output format. Must be default or json.
  --debug                     Prints extra info to debug the commandline.

I think the problem is that some options will "hide" ones for the parents. And since one option can have more short/long names, it could be that one name is hidden and the other is not... And to make the real calculation we would have to show only the names that are not hidden, and hide the option altogether if all the names are hidden. In principle it's doable... though I am not sure I'd know what's the best way to do it in the context of the library.

For my own purposes, I can simply hide the extra help options, because I'll never have other options that clash with one another. And, since I can always do that with a custom formatter, once 1.6 is out as it is I should be fine. I imagine, though, this uglier implementation would be good enough for 99% of the cases... If someone uses fallthrough it is precisely because the options are not hidden. So, implementing the extra fancy case may be very complex but not very useful. Maybe the simple implementation could be default and add the problem in the known issues?

[altairwei]

Has this function been implemented? Or is there another way to define common options?