search

gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source
https://gno.land/
Other
839 stars 342 forks source link

[gnokey] Make `gnokey query` more convenient #2349

Open leohhhn opened 1 week ago

leohhhn commented 1 week ago

Description

This issue related to a few issues in gnokey, specifically related to how we parse data when doing an ABCI query to the chain. In this case, I am referring mainly to vm/... queries.

Currently, the --data flag takes in all of the data for the query, but this is inconvenient because of the way parsing works - see this issue for example.

Another issue that we have is that we cannot currently list available ABCI queries via the CLI - you either have to go to the docs, or read the code.

I have two proposals:

  1. Split the --data flag into --pkgpath & --func/--arg or similar - this approach could work, but only ~one~ two queries currently, ie vm/qeval & vm/qrender, actually take in more than the package path. It would make a mismatch/useless flags for other current queries, and it could create a problem when/if we add more ABCI queries.
  2. Add query subcommands with their own flags to the main query. This would enable us to have subcommand-specific flags, and have them have their own proper flags. This approach would be more clean, but it would also limit the addition of new ones, since the subcommands could pile up over time if we choose to add more and more queries.

Both of the above proposals have both pros & cons, but I believe that it could be the way forward, as we might not be adding more subqueries in the future. It would be a compromise.

I would like to hear input on this @moul @zivkovicmilos @ajnavarro @thehowl

moul commented 1 week ago

The gnokey query command is currently a general-purpose tool, similar to curl -X POST --data.

I believe it should remain this way, so we can rely on gnokey to handle a wide range of calls.

Your second idea about adding subcommands (while preserving the current implementation) sounds good to me.

Alternatively, we could create new contribs/ for this purpose. I believe I have a PR or branch somewhere, where I've developed a gnokey-eval that addresses the parsing logic and provides improved -h usage documentation.

But IMO, subcommands are OK, since gnokey is currently specific to the gno.land blockchain.

The new subcommands should not have any implementation in tm2/crypto, as is the case for most of the gnokey implementation. Instead, the CLI should compose tm2/crypto and gno.land/-specific subcommands.