add back cli config option for flags

[okwme]

Summary

I noticed you can't use a command like gaiacli config keyring-backend test anymore.
It makes commands really cumbersome when you have to add a flag like that onto everything, is there no way to configure the command anymore?

Problem Definition

Proposal

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[migueldingli1997]

I also miss this command! Especially since I like to set up scripts with sometimes long sequences of transactions. Without the config, these sort of scripts will be less readable due to longer lines (Even though for this specific purpose I can set up functions which abstract away these flags)

[alessio]

It was a hack-ish, manually maintained tiny thing that I wrote originally long time ago. I was never aware that it was so much used.
We need to bring it back.

CC'ing @jgimeno @sahith-narahari @fdymylja

[fdymylja]

If we could understand better the scope of this. What is the reason? Is it to support multiple chain configs from the same daemon?

[alessio]

If we could understand better the scope of this. What is the reason? Is it to support multiple chain configs from the same daemon?

Nope. Cosmos SDK applications used to read client configuration from an INI file. Such file could be edited either manually or via the command appcli config KEY VALUE, e.g. gaiacli config keyring-backend file. In a way, it kinda resembled git config's behaviour.

[clevinson]

@alessio is someone from your team addressing this or should we assign someone from the regen side?

[alessio]

Do you want to include this in v0.42? If the answer to the latter is yes, then yes please feel free to reassign to someone at Regen as we are at capacity (plus, our backlog is growing).

[amaury1093]

I'm not sure if it's in scope of this issue, but a refactor of the whole config situation would be cool: #8132 (comment), and might make this task easier.

[alessio]

Yes, I agree 👍

[alessio]

C'ing @gsora

[clevinson]

@cyberbono3 who has just joined the regen team will be taking a look at this from our side :)

[aaronc]

One of the reasons for removing this is dependency on a global viper object. We will need to figure out how to do this cleanly without using globals. Maybe a scoped viper instance or something totally outside the viper stack.

[amaury1093]

Just had a talk with @cyberbono3 on this. I believe people want this on the hub right now, so i propose 2 steps:

• Step 1 (will be backported for the hub). Add the config subcommand as described in the 1st post, which is non-breaking. I'm proposing to create a new $NODE_DIR/config/client.toml file to hold all client-side configuration (e.g. keyring-backend, node, chain-id etc...). Basically what @alessio described in add back cli config option for flags #8529 (comment).

  • note: this won't pollute app.toml, which is more server/node configuration.

• Step 2 (for 0.43+). Think about refactoring config as a whole, with the objectives in mind to:

  • remove dependency on singletons
  • make sure we have the exact same configurable variables via flags, ENV variables and config file, and define a priority between them when multiple are set

Any feedback on this?

[alessio]

Just had a talk with @cyberbono3 on this. I believe people want this on the hub right now, so i propose 2 steps:

• Step 1 (will be backported for the hub). Add the config subcommand as described in the 1st post, which is non-breaking. I'm proposing to create a new $NODE_DIR/config/client.toml file to hold all client-side configuration (e.g. keyring-backend, node, chain-id etc...). Basically what @alessio described in #8529 (comment).

  • note: this won't pollute app.toml, which is more server/node configuration.

• Step 2 (for 0.43+). Think about refactoring config as a whole, with the objectives in mind to:

  • remove dependency on singletons
  • make sure we have the exact same configurable variables via flags, ENV variables and config file, and define a priority between them when multiple are set

Any feedback on this?

Sounds like we have a plan!

[amaury1093]

Step 2 (for 0.43+). Think about refactoring config as a whole, with the objectives in mind to:

This is tracked in #9034