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
842 stars 343 forks source link

CLI refactor #731

Open moul opened 1 year ago

moul commented 1 year ago

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

Proposed changes:

Read recent discussion at https://github.com/gnolang/gno/discussions/623 Related with #460 Continues #497 Fixes #729

grepsuzette commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

From https://github.com/golang/go/issues/40138

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

albttx commented 1 year ago

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)

moul commented 1 year ago

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 commented 12 months ago

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 commented 8 months ago

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

thehowl commented 7 months ago

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 commented 7 months ago

@salmad3 @jeronimoalbi

moul commented 6 months ago

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: