Ban usage of positional arguments

[dpc]

When working with real software positional arguments are very inconvenient.

• They are not self describing, so it's just harder to read and understand them.
• When messed up by the user the feedback is poor, as it's hard to determine which thing exactly is missing and where.
• (when available) shell autocompletion can't do as good job with them.
• (AFAIU) They don't support environment variables
• They can't be reodered, which is very handy for scripting, or when one wrote a long command invocation, and forgot only one argument somewhere.

The only time when positional arguments are OK is when the command really does have a one central argument that is very primary and mandatory. Like cat takes file paths. It would be somewhat annoying the have to do cat --path somefile --path someotherfile. But that's usually only a concern for commands really meant for short-form interactive use.

I'd like us to stop using positional arguments.

[elsirion]

I'd say a second exception are subcommands. E.g. gateway-cli could live on as fedimint-cli gateway <args…>.

[dpc]

I'd say a second exception are subcommands. E.g. gateway-cli could live on as fedimint-cli gateway <args…>.

Not sure if I understand you, but I don't think I've ever seen subcommands being non-positional. Is it even doable? But agreed - subcommands are highly positional.

[elsirion]

I have seen software where subcommands were implicitly accomplished using mutually exclusive flags, which I find rather annoying. So yeah, please let subcommands be positional.