refactor: reorganize project, isolate components (tm2, gnovm, gno.land, ...)

[moul]

BREAKING CHANGES:

• The build instructions have been altered, so the tutorials need to be revised accordingly.
• The import paths have been changed, any external repositories that depend on gno will not be able to compile if they update their dependencies.

---

• Create a top-level gnovm, gno.land, tendermint2 folders. No more top-level pkgs, cmd folders.
• Decide how to handle the case of pkgs/std (see comments below).
• Update CI, split it by main component.
• Create/update */README.md and update top-level one too.
• Create/update */Makefile (when it makes sense) and update top-level one too.
• Add a disclaimer on tm2 upstream README.md, linking to this PR. (chore: add disclaimer pointing to gno monorepo tendermint/tendermint2#12)
• Cleanup unused files (old protos).

---

Next steps (new PRs):

• Migrate tm2/pkg/sdk/vm and pkg/crypto/keys/client parts depending on gnovm either in gnovm or gno.land.
• Setup go mod workspaces.
• Create standalone tm2 demo chain + client (done in chore: post-split cleanups tendermint/tendermint2#1).
• Setup vanity URLs for tm2 and "the rest".
• Improve CI, ensuring tm2 won't depend on nothing "gno*", i.e., grep gnovm from dedicated go.mod.

Addresses #577

[moul]

Current thinking:

GnoVM can be run independently of Tendermint2, such as with Tendermint1 as a module or with a custom implementation outside of the Cosmos ecosystem. Therefore, GnoVM should not rely on any imports from T2.

We have a shared package named std which is imported by both T2 and GnoVM. An alternative to splitting each package into its own std package is to create a separate folder such as common or types. However, I do not prefer this option as it can lead to confusion. My current preferred option is to consider that T2 depends on GnoVM, which does not require enabling full smart-contracts features on a T2 chain, but rather is focused on managing consensus and networking. Tokens and other objects are built into GnoVM.

My goal is to compete with Cosmos-SDK by providing a way to customize a blockchain with contracts. This does not preclude the possibility of adding Cosmos-SDK as well.

I suggest that we maintain std within GnoVM and import it from T2.

If it is essential that T2 does not rely on GnoVM, I can create an interface for the std package while keeping the implementation in GnoVM and the connection in gnoland.

[moul]

I would like to suggest the following regarding a global monorepo architecture:

* README.md, Makefile, .github, editor configs, etc
* gnovm/
  * README.md, Makefile, ...
  * tests/
  * pkgs/
    * gnolang/
    * std/
  * stdlibs/
  * cmd/
    * gno/  # new name for `gnodev`
    * gnokey/
* tendermint2/
  * README.md, Makefile, ...
  * pkgs/
  * cmd/
    * t2c/ # generic tendermint2 client
    * t2txsync/ # previous gnotxport
  * sync-with-upstream.sh # or similar
* gno.land/
  * genesis/
  * cmd/
    * gnoweb/
    * gnoland/
* examples/gno.land/{p,r}... # we keep this at root level
* misc/ # for scripts, helpers, and things for advanced usages.

[jaekwon]

In pkgs/std, most files are needed for Tendermint2 only, not Gno.

• pkgs/std/account.go could move into pkgs/sdk/auth/types.go or elsewhere in the sdk.
• pkgs/std/coins.go could move into pkgs/coins, but I think it's worth keeping it and making accessible to TM2.
• most of the rest are for Tendermint2.

I think TM2/std should act as a type of "common" type. This goes along with TM2's goal of being a swiss army (#2 in https://github.com/tendermint/tendermint2 for now anyways). When we need to we can create adapters between TM1 and TM2, but TM2/std is an opportunity to make breaking changes and imagine what is a good "common" from a blank slate.

So I would say that GnoVM and gno.land should import from TM2/std.

[jaekwon]

Also suggest gnovm -> gno and tendermint2 -> tm2 for succinctness, tm2 to be renamed later.
Are we assuming that the plan is to split tendermint2 out later?

[moul]

Are we assuming that the plan is to split tendermint2 out later?

Eventually, but still by keeping a fork in the gnolang organization and synchronizing changes manually when it makes sense. See #577 for further discussions.

[grepsuzette]

I think gnovm is a better directory name than gno though.
Because when cloned, the parent is going to be called gno already.
It will help beginnner to understand what is what. I like tm2 better as well.

[moul]

I think gnovm is a better directory name than gno though.

I had the same thought as you while I was implementing it.

The name of gnodev will be changed to gno, as initially proposed in issue #482.

-> github.com/gnolang/gno/gnovm/cmd/gno

[moul]

Summary of the last discussion:

• continue the folder reorganization to improve the separation of concerns, discoverability, simplicity, and focus.
• github.com/tendermint/tendermint2 will be updated with a disclaimer saying that we focus dev effort on the gno monorepo until it becomes stable (@jaekwon).
• update t2/README.md with a disclaimer saying we'll extract the work one day.
• skip the need for a script now; we'll figure out this later if it makes sense.

[harry-hov]

LGTM. 💯

[zivkovicmilos]

I'm a bit late to the party, but this looks great 💯

I love that it's much more streamlined now and easier to follow, especially for new contributors. I also had to look up the syntax in the nested Makefiles and learned something new 🙂

[moul]

Thank you all for the review; I'll make a last rebase with master, wait for green CI, and merge.