META 'gno' CLI (DevX discussion)

[moul]

This issue aims to centralize discussions, issues, and pull requests related to the gno CLI—a powerful tool for GnoVM development without blockchain devops/expertise needs.

0ur goal is to make the gno CLI an all-in-one/one-stop binary for developers, similar to how the go binary is for Gophers.

We want it to offer a seamless experience, enabling developers to accomplish various tasks easily.

@gnolang/core-contributors: Please share your visions, ideas, and wishlist in a comment. We'll extract the best concepts into dedicated issues, working towards this target.

Related to #972.

[moul]

Proposal for expected usage (personal opinion):

## Simplified `gnokey`, streamlined account management, and chain querying

# Create a 'manfred' account (first account becomes default, no need for --account flag).
$ gno accounts new
Username: manfred
...

# Optionally, register 'manfred' username on https://gno.land/r/users.
$ gno accounts register manfred

# Or register 'manfred' username using a single command.
$ gno call gno.land/r/users Register manfred

## Fetch sources and states from the chain for local development

# Fetch source + state from the chain.
$ gno get gno.land/r/users

# Update state (fetch new registered users).
$ gno get -u gno.land/r/users

# Create a contract importing gno.land/r/users ("Gno Connect").
$ $EDITOR my-contract.gno

# Run the local contract with persistent state using 'manfred' wallet.
$ gno call ./my-contract.gno MyFunc arg1 arg2 arg3

## Evaluation, both online and locally

# Call the Register method from gno.land/r/users online with 'manfred' as an argument.
$ gno call gno.land/r/users Register manfred 

# Call the local contract (with persistency); method is Foo, and bar and baz are args.
$ gno call ./my-contract.gno Foo bar baz

# Call a contract on the local chain.
$ gno call local.land/r/users

## Debugging and convenient tools

# Use eval for the RPC call `q_eval`, read-only, gas-less, to display a value, a function, etc.
$ gno eval gno.land/r/users 'accounts'
[
  {...},
  {...},
  ...
]

# Use exec for the new `exec` gnovm endpoint, which simulates publishing my-contract, executing it from my user realm, and deleting it; a way to make a transaction with arbitrary gno code.
$ gno exec ./my-contract.gno

## `gno` to power other apps and tools (IDE, CI/CD, etc)
$ gno _ list
...

To be continued...

[mvertes]

Following, my view on what is Gno and its many facets, and how it translates to the CLI.

1. Gno is a programming language very close to Go. Not only the language but also the tooling, the standard library as a model for APIs, and the general philosophy:
   • have a single executable (gno), self-contained, with self-help, and sub-commands covering the whole life cycle of developing, building, testing, running, but also deploying and publishing Gno programs aka smart contracts.
   • limit the dependencies to the strict minimum: a text terminal running a shell (i.e bash or other), in the most advanced usages, a web browser connected locally to gno in server mode (similarly to the go profiling tool experience: go tool pprof -web ...). We may need the Go toolchain for a while, but not indefinitely. I expect that at some point, only gno is sufficient.
   • in development and test mode, everything should run locally, disconnected. The remote parts should be simulated if necessary (without having to use docker or other complex systems). This is an enabler for quick-starting, but also for efficient CI-CD processes. Having every sub-command and modes in the same executable should help to achieve this.
2. But Gno is more than just a programming language and tools. It provides a blockchain system which can be seen as a database server where the gno executable is a client connected to it. In that context, having a CLI allows to interact with the server. For example, the Mongo shell is used as an interactive Javascript interface to MongoDB. In our case, gno repl would be used as an interactive Go interface to the Gnoland blockchain. It is expected to interpret the Go syntax, provide some Go standard library packages, some package to perform CRUD operations, and could also support at some point advanced queries (join, group, filter, etc) as exhibited by a SQL driver or other.
3. But Gno is also more than a database. It is one live, massively distributed peer-to-peer system, with users, per-user accounts and storage, and also per-user packages and apps (the smart contracts), where users, if I get it right, can be a person or a contract. It can be seen as a single virtual machine with running processes (smart contracts), with a global filesystem organised as a hierarchic storage. This filesystem view is at least necessary to allow the package dependencies to work (so a smart contract can import a package provided by another user). So the repl should provide access to these virtual filesystems, at through the Go io/fs. Having classical unix commands like ls, cd, ps, who, etc, operating on this VFS and available from the CLI make sense too.
4. This global filesystem has also properties inherent to versioning systems: it has history built in (coming from the blocks in the blockchain), allowing to access (potentially) snapshots and past versions, which are store securely and immutably. I think that we should be careful to provide a way to expose the snapshots or past versions through io/fs too.

[moul]

See #1201 for recent related discussions.