CLI command to show all confirguration options

[chrisjsewell]

Currently, unless I am mistaken, there is no way to quickly view all configuration options for a profile: verdi profile show has an options line, but only shows options specifically set as global overrides, verdi config has auto-complete of configuration names, but does not show their current values.
It would be nice to be able to see all the configuration values for a profile without having to search through the code for the defaults.
Perhaps verdi config should have an extra level, i.e. verdi config set and verdi config show, and there could be verdi config show --all, with a * to denote values that override defaults, e.g.

$ verdi config show  daemon.timeout
10
$ verdi config show --all
daemon.timeout:           10
*daemon.default_workers:   2
... 

[chrisjsewell]

Mainly I guess it would be just pretty printing:

aiida-core/aiida/manage/configuration/options.py

Line 25 in 99e608c

CONFIG_OPTIONS = {

[sphuber]

Note that the current design was intentional and mirrors the interface of git config. It would be good to try and follow that for consistency.

[chrisjsewell]

well I'm not convinced that is necessarily the best part of the git CLI lol. But anyway, if we want to mirror that then (a) it has a list option git commit --list --show-origin and (b) it lists all the configuration variables, descriptions and defaults in its (very lengthy) git config --help (but this isn't trivially possible with click)

[sphuber]

I am not sure, but your assessment of the current status of verdi profile show may be based on a misunderstanding. You say:

verdi profile show has an options line, but only shows options specifically set as global overrides

But that is not true, it shows the options that are specifically set for that profile.

However, I see your point that it might be useful to see the defaults of certain options and their description from the CLI, and agree that we should not stick to the original git design at all costs if we really think it is not optimal. So I am happy to consider an alternative. In that case, we may also want to think how to include the configuration for the caching, which I haven't included under verdi config because of the current design, but as you mentioned in that PR, if we change the interface, it may make more sense to have with the rest of the config. Especially given that the plan is to merge the caching config file in the normal config.

Maybe we should first draw up the new envisioned interface and sign-off on it before starting to implement, in order to prevent length back and forths on a PR.

[chrisjsewell]

folding in to #4584