EPIC: AutoCLI & hubl

[aaronc]

User Story

As a module developer, I want the framework to automatically generate CLI commands from protobuf Query and Msg service and ORM table definitions so that I don't have to manually write and test these commands.

Phase 1: Basic Support

• feat(cli): dynamically generate query CLI commands #11725
• AutoCLI flag, positional parameter and help text customization
  • feat: add auto-cli customization options #11763
  • feat: implement autocli customization #13251
• AutoCLI app wiring + remote info support #13282
• Dynamic client metadata #13310 (still open, but finished as far as autocli is concerned)
• AutoCLI app command generation #13283
• AutoCLI Sane Kebab Case #13499
• Add AutoCLI options for each module #13293

Phase 2: Enhanced Support

• AutoCLI YAML output #14707
• AutoCLI basic Msg support #13284
• AutoCLI custom Coin handling #13286
• AutoCLI bech32 validation of address strings #13287
• AutoCLI support for JSON files #13288
• AutoCLI support for binary files #13289
• AutoCLI map support #13290
• AutoCLI multi-chain command #13285
• tools: add docs on how to use hubl #14740
• feat(client/v2): support consensus address decoding #16927
• feat(auth,client/v2): add validator address codec #16768
• feat(client/v2): stringify bytes cosmos.Dec #16985

Phase 2.5: Module customization

For each module in the SDK, add autocli options following the pattern in x/auth/autocli.go. These options should:

• Provide proper documentation, usage strings and examples
• Correctly set required fields as positional parameters
• Add Query Module Configurations for AutoCLI #15901
• AutoCLI improve default value handling #14719
• Allow combining AutoCLI commands and existing commands #16836

Phase 3: Full Tx Support

• Improve binding of message in AutoCLI #17478
• Add clientCtx to commands #17423
• AutoCLI Keyring #14744
• AutoCLI resolution of key names in the keyring
• AutoCLI tx signing #17765
• Add Txs Module Configurations for Autocli #17808

Phase 4: Full parity with existing CLI

Support for genesis related stuff, node status, tendermint blocks and events, etc.

• Use AutoCLI for non module commands. #17190

Phase 5: ORM Query Support

To be specified once #11774 is completed.

[tac0turtle]

ref #3558

[aaronc]

@AmauryM this should probably reuse the same Coin functionality as textual. That is something we could put in core, but the need here is also for a protoreflect version which I think should be generic enough to not depend on a configurable denom regex

[amaury1093]

I can put this function into core:

cosmos-sdk/tx/textual/valuerenderer/coins.go

Line 150 in 1fdbea5

func formatCoins(coins []*basev1beta1.Coin, metadata []*bankv1beta1.Metadata) (string, error) {

This function IMO shouldn't depend on any regex, it should assume all denoms inside Coin and Metadata are valid.

[aaronc]

One pending discussion from #11877 is:

We would like to be able to customize:

• short and long usage strings for commands
• aliases for flags (ex. -a for --amount)
• which fields are positional parameters rather than flags

It is an open discussion
as to whether these customizations options should line in:

• the .proto files themselves,
• separate config files (ex. YAML), or
• directly in code

Providing the options in .proto files would allow a dynamic client to automatically generate
CLI commands on the fly. However, that may pollute the .proto files themselves with information that is only relevant
for a small subset of users

I think we should have as a goal:

• clients need to download one binary (i.e. lens or cosmos-client),
• that works for all chains by pulling the CLI info dynamically,
• clients don't need to upgrade the binary for chain upgrades (everything is pulled dynamically)

I tend to agree with the perspective that CLI options in .proto files might bloat them a little. If we don't do them in the .proto files, I would want a similar client distribution system that accomplishes the above. It might be that using the .proto files is the simplest approach because the existing gRPC reflection API will be sufficient (just pull the FileDescriptor's and that's it).

[aaronc]

I updated #11763 with an example using a .yaml file. The same thing could be done in a go file and it would really be the user's choice. How does that look @AmauryM @marbar3778 ?