Parity-ethereum: Config options without CLI behind them

[tomusdrw]

It should be possible to create config entries without creating additional CLI options.
or
We should have --help and --help --verbose :)

[guanqun]

This looks like a small enough issue for me to dive in, but I don't quite get what you mean. Do you mean we should support --help --verbose instead of reporting Unknown flag?

[rphmeier]

@guanqun Right now our help message is really big. The feature here is to reduce the CLI help to only essential options unless specifying --verbose to make the message more approachable.

[guanqun]

Ah, I got it. It's like git help vs git branch --help. :)

[rphmeier]

Yep, something like that. I think this would be an awesome opportunity to port our CLI to clap over docopt, but that would be a much larger change.

[tomusdrw]

The issue here is also that currently any option that is available in config file needs to have a CLI argument, we can start with a possibility to have config options without CLI flag behind them and move some advanced CLI options to config files.

[guanqun]

From the comments we want to do two things:

• convert docopt to clap
• remove some advanced CLI arguments from the CLI options. For this one, I don't think I'm in the right position to say which one should be removed. :) Hopefully someone can come up a list.

[axelchalon]

I'm currently porting the CLI to clap (#2066) and it will then be possible to have options that can only be set from the config file. To reduce the output of the help message, we could have each subcommand have its own help message (i.e. parity account --help) for example; I think this is the standard way on clap.

[debris]

any update on this? is it possible now?

[axelchalon]

Marek:

Separating global help from help of subcommands
parity --help only shows global options, and the options for a specific subcommand are shown by parity account --help for example, so this already reduces the size of the help outputs in general.

Hiding some options from the CLI help output
Currently, the parity --help output (for the global options only) is generated by us (this lets us divide the options into categories in the help output, etc.), so we could decide for example to not show the options if they, say, have an empty help message. This would be easy to implement. For this to also work for subcommands help outputs (parity account --help), we could generate those outputs ourselves rather than let Clap automatically do it, or more simply internally use .hidden() on clap args. Anyway, this would be doable.
I would imagine that it's best to show all the available options in --help but do you have some in mind that shouldn't appear?

Short help vs long help
Clap supports -h for displaying a short help output, and --help for displaying the long help output (like --help --verbose that you were discussing). Currently we only have a single help message that is dispayed regardless of the help verbosity level.
Using this feature would mean being able to specify a short help and a long help message for each option. This could make the CLI mod.rs quite big.
We could also derive the short help message from the long help message; it could be its first sentence. What do you think?

[5chdn]

Thanks for continuously working on this @axelchalon.

I have a proposal, could we somehow format the help output that it does not extend 80 (or 120?) chars in width? It is not very readable on wide screens. Thanks :)

[axelchalon]

@5chdn : Sounds good! Working on this.

[axelchalon]

PR #7626 Wrap --help output to 120 characters

[folsen]

@axelchalon What is the current status of this? Could we get a summary on this issue and an actionable list of what needs to be done so that someone can pick this up. This is potentially an issue we could create a bounty for.

[axelchalon]

Sure! First off, to clarify: @tomusdrw could you specify what exactly you had in mind when you opened this issue? I imagine you find the current output of --help too long. When printing the help by default (in non-verbose mode), would for example shortening the help messages for each option, or skipping some rarely used options be good solutions for you?

[vs77bb]

Hi @folsen @axelchalon I'll hold off posting the bounty until the scope is clarified 👍

[rphmeier]

@axelchalon sounds like basically the same thing. --help and --help --verbose being different, but the config TOML still being able to affect those flags might be enough. But we might want to go a step further and have config options that are not CLI flags at all.

[5chdn]

Can we remove "Legacy Options" from --help?

[5chdn]

Can we remove "Legacy Options" from --help?

Can help out here, just couldn't figure out how to hide them without breaking the whole logic of managing the CLI options.

[axelchalon]

@5chdn wrapping if $group_name != "Legacy options" { ... } around https://github.com/paritytech/parity/blob/dec390a89fe038337399315daf15e628ffbb4d8e/parity/cli/usage.rs#L446-L509 does the trick.

[adria0]

Closing the issue due to its stale state