CLI: Use flags everywhere instead of positional arguments

[romac]

Summary

All CLI commands should use flags (--flag) options instead of positional arguments.

Problem Definition

At the moment, a lot of the CLI commands use a mix of positional arguments and flags, for example
the create channel CLI:

hermes create client ibc-1 ibc-0 --trusting-period 14days
                     ^^^^^ ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
                      positional          flag

When writing the commands it is now always clear what the positional arguments denote (eg. which is the source chain and destination chain), and one often has to resort to the command documentation (--help) to figure it out.

Even worse, the number of positional arguments and their denotation for the create channel command change depending on which flags are passed, eg.

hermes create channel ibc-0         -c ibc-1 --port-a transfer --port-b transfer --new-client-connection
                      ^^^^^         ^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
                      positional    flag     flag              flag              flag

vs

hermes create channel  ibc-0       connection-0 --port-a transfer --port-b transfer
                       ^^^^^       ^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
                    positional      positional        flag               flag

This is quite confusing, as expressed already by some operators: #1935

Proposal

I suggest using flags everywhere instead of positional arguments.

Positional arguments should be kept for the case where we want to pass a list of items to a command, which we don't have the need for currently.

Acceptance Criteria

All CLI commands accept only flags and no positional arguments.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ljoss17]

Hey @adizere and @romac .

I would like to use this issue in order to apply the following guidelines for the CLI command codes:

1. Explicitly give long and/or short flags. E.g:

    #[clap(short = 'a', long = "amount", required = true, help = "amount of stake")]
    amount: u64,

2. All flags which start with the character c would only have a long flag, to avoid conflicting with the global flag -c/—config
3. All flags referencing the height would have the short flag -H and all other flags starting with the character h would only have a long flag to avoid conflicting with the global flag -h/—help

Would you consider this a good idea ? Or am I maybe missing some additional guidelines ?

[romac]

I think we should get rid of short flags altogether so that we don't have to deal with conflicts and make everything consistent. What do you think?

[ljoss17]

Seeing the amount of fields with only long flags, for example all the chain_id, conn_id and client_id, I also think that removing all the short flags seems like a good idea.

[romac]

I would also suggest we drop the -id suffix in all flags to make the flags shorter and easier to type.

[plafer]

Or maybe global flags should be long form only, as there are less of them and are optional, and have a short form for the other flags? I find short flags to be quite nice when you are running a lot of commands; explicitly typing out the long form args over and over can get annoying and distracting. And hermes commands typically have many of them.

WDYT?

[ljoss17]

Generally I prefer having short flags, but after passing through the commands of this CLI I saw that there aren't only potential conflicts with global flags. There are many commands which would require finding a meaningful short flag which isn't the first character. The following are some examples of commands which would require special short flags:

• chain_a_id, chain_b_id, client_a_id, client_a_id for the command: create connection
• dst_chain_id, src_chain_id, dst_conn_id, dst_port_id, src_port_id for the command: tx raw chan-open-init

So I am a bit more in favor of having the default being all long flags, but reducing the length as @romac suggested so chain_id would be chain etc...
But if we are able to find a meaningful solution for all the conflicting cases, the short flags could be a nice addition.

[adizere]

One source of insights would be to check the gaiad CLI as well as the rly CLI, and see how they deal with some of the corner-cases we're identifying here. For example: Do they use long-only options? What do they do with short options in case both side "a" and side "b" are necessary?