ffcli philosophy and developers habbits

[tbruyelle]

ffcli requires to position the CLI arguments at the very end of the command line, or else it's not able to parse properly and outputs an error flag: help requested

Example :

$ gnokey broadcast signed.tx -remote "127.0.0.1:26657"
USAGE
  broadcast [flags] <file-name>

FLAGS
  -home /home/tom/.gno            home directory
  -insecure-password-stdin=false  WARNING! take password from stdin
  -quiet=false                    suppress output during execution
  -remote 127.0.0.1:26657         remote node URL

flag: help requested

The accepted command is :

$ $ gnokey broadcast  -remote "127.0.0.1:26657" signed.tx

because here signed.tx is an argument.

This is annoying in a context of developers that are used to CLI where you can put your flags whatever you want. I personally found that disturbing, so I assume it would be the same for others.

One thing that could avoid this annoyance is to stop using arguments, and put everything in flags.

For instance, instead of :

gnokey broadcast -remote "127.0.0.1:26657"  signed.tx

we could have

gnokey broadcast -remote "127.0.0.1:26657"  -txpath signed.tx

In that case there's no possible ordering issue, we can write -txpath before -remote it's not a problem.

[zivkovicmilos]

Hey @tbruyelle,

I completely agree, it's annoying to have to watch out for argument positions, otherwise they don't get picked up correctly in the command. As you've mentioned, it's due to the way ffcli does flag parsing (relevant issue).

This has been just a UX pain-point. I'll look into opening up a PR on ffcli that solves this, and we can take it from there

[tbruyelle]

It would be nice if you can add this feature to ffcli. Because else I fear this UX pain-point can raise complains from users indefinitively.

[grepsuzette]

Yes! Agree with Thomas. Why not forking it in fact.

The project philosophy is "flags first".
We could instead allow:

• argument last (already working),
• argument first (trivial? check for the absence of a leading -).

Forking would also help making our call stack trace more centered on gno.
We could change the name to a boring one such as parsecli.
The last few lines of call stack showing another repo at times can be surprising.

That being said, I'm not sure if this is urgent.

[tbruyelle]

To be honest I wouldn't impose any order, people are used to order args and flags as they wish, so let's remove that regression.

[moul]

I consider it crucial to maintain the order of not allowing the setting of a child flag before the child command. However, once the CLI starts accepting input, I would be open to accepting any other order.

[moul]

Thanks for your feedback. I agree with your suggestions and have proposed changes. Please see: #731.

[tbruyelle]

With #762 merged, flags can be passed after command arguments.