gno [-watch] dev PATH

[moul]

Quick Summary: Utilizing gno dev . initiates an in-memory instance of gnoland and gnoweb. This action also preloads local contracts and their dependencies. When -watch is appended, automatic reloading takes place with any local contract alterations.

---

Thanks to @gfanton's contributions in #1117, the implementation of this task is poised to be more straightforward.

One of the more intricate facets I'm pondering isn't strictly technical but revolves around streamlining our codebase. The aim is to retain the minimalistic essence of tm2/ and gnovm/, ensuring they remain simplified CLI tools devoid of complex CLI shorthands. However, a comprehensive single binary named gno is envisioned. This won't just be limited to gnoland or the specific gno.land chain but will stand as a cornerstone for the "gno ecosystem." This holistic tool would encapsulate complexities, presenting a unified interface tailored for routine tasks, from executing local contracts off-chain to fostering interchain interactions.

Therefore, I propose the following restructuring:

1. Extract gno from gnovm/, ensuring gnovm/ remains uncluttered. If there's a necessity, we can architect new binaries within gnovm/cmd/{gnovm,gnolang}. This separation would support distinct functionalities for gnovm and gnolang. However, immediate action on this seems premature.
2. For now, placing the gno binary at the repository's root seems appropriate. Over time, a dedicated subdirectory, perhaps labeled gno/ or ecosystem/, could emerge, but currently, our existing directories should suffice.

Another forward step involves leveraging the split in tm2 (#692). This would accommodate go mod workspaces, enabling both tm2 and gnovm to benefit from streamlined go.mod files. The overarching "gno ecosystem binary," with its developer-centric inclinations, would subsequently harness a more expansive dependency framework. This particular binary is unique; it's not designated for repetitive forking for new gnovm+tm2 based chains. Unlike tm2 and gnovm, which are generic, straightforward, and finalized, this binary will encapsulate more intricate workflows.

---

For further insights, I'll soon offer an in-depth breakdown. Meanwhile, these references might be helpful:

• Ease local dev while keeping gnoland minimal #1020
• CLI refactor #731
• META 'gno' CLI (DevX discussion) #1017

We've also had several enlightening voice discussions, which you might find on YouTube for a deeper understanding.

[gfanton]

I would like to proceed with moving gnovm and gnolang out of tm2, enabling us to iterate and establish a workspace. Following the comments from @moul @piux2 @tbruyelle https://github.com/gnolang/gno/pull/825/files#r1279927834

What would be the best approach as of today:

1. Move the entire tm2 key/client into gno.lang/cmd/gnokey (or gno.lang/pkg to keep its API open), possibly retaining some helper functions in the key package.
   EDIT: same as 3.

2. Transfer only the run, call, and addpkg files/logic to gnokey. However, key/client will need a way to expose certain methods/structures to avoid duplicating code.

3. Transform keys functionality into a library (not a command-line API) and shift all the CLI components to gnokey, along with specific features like addpkg, call, run. I believe this is the best compromise as we want to keep tm2 minimal and simple . If really wanted, we could even maintain the CLI API within gno.lang/pkg.

4. ... other ideas ?

[moul]

Ultimate target (not a strong requirement before a few years):

• TM2 provides libraries for building TM2-powered blockchains and clients. Unaware of "gno".
• Gnovm provides libraries for building systems using Gnovm, eventually including an official TM2+Gnovm SDK.
• Gno.land contains custom code that is specific to Gnovm/TM2-based blockchains.

Short/intermediary target:

• TM2 is unaware of Gnovm and Gno.land.
• Gnovm can import TM2 (e.g., for std.*), but ideally should not be aware of what a blockchain is and is completely unaware of Gno.land.
• Gno.land contains custom code AND can contain unfinished/not-generic-enough components, once they are sufficiently generic and clean, they can be moved elsewhere (in tm2, gnovm).

---

In other words, you have two main options:

• You can make a slower pull request (PR) that moves run/call/addpkg to gnovm/pkg/tm2gnosdk (or another name) to achieve the ultimate target.
• Alternatively, you can move them to gno.land in a pkg/ or cmd/ (up to you). This allows us to split the code now and maintain the freedom and flexibility to make it more generic later (or not).

I recommend choosing option 2. Honestly, even I am unsure about how things will develop, and I lack confidence in my ability to draft something sufficiently generic and effective on the first attempt.

[tbruyelle]

I think moving tm2/client to gno.land/cmd/gnokeyis still the best approach in my opinion.

[moul]

I suggest we approach this as if the tm2 client never originally existed in tm2 but was developed in gno.land. Then, if someone wants to create guilhem.land and aims to reduce repetitive code, they could add helper functions to tm2. These additions would exclude gnovm-related elements, focusing tm2/pkg/client on simplifying client creation.

In my opinion, directly extracting gno might be more challenging. A two-step process would be more effective, starting with removing the client from tm2 and then working towards maximizing shared code.

Although some may have reservations about this plan, I believe now is the ideal time to implement it. Currently, we lack a secondary chain, making it an opportune moment to proceed. This action would enhance simplicity in the short term and provide a better context for designing improved shared helpers in the future, when they are truly needed.

[thehowl]

re: what to do for keys/client, we discussed with jae and decided on this approach.

@gfanton should this issue be closed as gnodev has been added, or do you envision closing this after we add some other bits of functionality?

[gfanton]

@thehowl I think it's fine. The main target of this issue has already been addressed in #1386. I'm closing this. If I missed something, feel free to reopen it.