CLI refactor

[moul]

Following various discussions, issues, and PRs; I've a proposal for a new (and final?) refactor of the CLI.

Proposed changes:

• Remove ff/ffcli dependency, focus on a minimalist flag management approach. Fork it, keep the spirit, make it better, for gno. fix(cli): accept flags after command's arguments  #762
• Replace the static flagset with a flagBuilder callback that can lasily be called recursively to support setting parent flags from a child command. feat: add support for toml configuration files + recursive flag definitions for subcommands #827
• Add support for passing flags after the args (TODO). fix(cli): accept flags after command's arguments  #762
• Add a file-based toml driver by default; make the CLI always looking for flags, then files, then default. feat: add support for toml configuration files + recursive flag definitions for subcommands #827
• Transition from single-command to subcommands for gnoland, beginning with init and run. refactor(gnoland): add subcommands support #937
• Add support for short flags.
• Port existing config file args as arguments, especially for gnoland.
• Make sure everything still has a simple API to use -> should not care about file/flags, etc.

---

Read recent discussion at #623
Related with #460
Continues #497
Fixes #729

[grepsuzette]

When a CLI system is mixed with a configuration system (either toml yaml or json...), and can inherit environment variable, I consider it's a very high-level system already.

I suggest to just fork ffcli into our codebase (step 1), and then to see what we do from there, step by step. This would fluidify execution of other tasks.

[moul]

I agree, and we can start with just the flag parsing part first.
But it's important to make it consistent and avoid the necessity of doing things like #729.

[moul]

@thehowl checkout this -> https://github.com/rsc/getopt/blob/master/getopt.go

From golang/go#40138

Edit: FYI @thehowl, #828 partially tackled TOML config file support for an existing command.

[albttx]

With the on-going discussion for running a multi-node testnet, i believe this issue is needed to be linked to it.

Of course, genesis files can be written by hand for the moment, but i believe we should consider to add useful tools to simplify validators works like: (as in cosmos-sdk based chain)

• gnoland add-genesis-account
• gnoland gentx
• gnoland collect-gentx

[moul]

Let's start by switching from a single command to multiple subcommands; then we can have PRs for each relevant addition.

Edit: see #937

[thehowl]

From discussions:

me: watching through zack's video tutorial on how to build a smart contract: https://youtu.be/F-_dadxcRJM?t=172\
I see that he says that the way to get tokens in a local testnet is by adding your key to the genesis balances file. However, this is in contrast to what we say, for instance, in the Getting Started tutorial we have on the testnets ( https://test3.gno.land/r/demo/boards:testboard/5 ), which instead suggests to use the given mnemonic, which is the corresponding mnemonic for the test1 key in the genesis balances file.
Which one should we suggest to use? A third option could be that of adding a flag to gnoland init to add an address to the genesis block without having to write to a file...

manfred: I'm for adding gnoland init and gnoland mint-token or other helpers
I'm also considering writing a simple script that will look for existing gno wallets on the FS and autoload them when running in dev mode

[notJoon]

Looking at the CLI Philosoph paragraph in the PHILOSOPHY.md, It says "No short flags", can I add this feature regardless?

[thehowl]

Looking at the CLI Philosoph paragraph in the PHILOSOPHY.md, It says "No short flags", can I add this feature regardless?

This is a conflict I was aware of, although I know informally we verbally said that we should still go in the direction of having (some) short flags.

wdyt @moul ?

[ilgooz]

@salmad3 @jeronimoalbi

[moul]

I recommend using short flags for common options, particularly if they are widely used in the Go binary or conform to Unix conventions. For example, -v can be used instead of --verbose. We should consider making the addition of short flags rare or even removing --verbose and considering -v as the primary flag instead.

Things to avoid include:

• Unclear "--help" messages
• Unclear commands in your history or when sharing them
• Redundancy in performing tasks (one method is usually better)
• Discomfort for long-time Unix/Go users