Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gno [-watch] dev PATH #1174

Closed
moul opened this issue Sep 26, 2023 · 6 comments
Closed

gno [-watch] dev PATH #1174

moul opened this issue Sep 26, 2023 · 6 comments
Assignees

Comments

@moul
Copy link
Member

moul commented Sep 26, 2023

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:

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

@moul moul moved this to 🌟 Wanted for Launch in 🚀 The Launch [DEPRECATED] Sep 26, 2023
@moul moul added this to the 🌟 main.gno.land (wanted) milestone Sep 26, 2023
@zivkovicmilos zivkovicmilos self-assigned this Sep 26, 2023
@gfanton gfanton moved this to Backlog in 🚪🔁 The Portal Loop Oct 3, 2023
@moul moul moved this from Backlog to TODO in 🚪🔁 The Portal Loop Oct 3, 2023
@moul moul moved this from TODO to Backlog in 🚪🔁 The Portal Loop Oct 3, 2023
@moul moul moved this from Backlog to TODO in 🚪🔁 The Portal Loop Oct 3, 2023
@moul moul moved this from TODO to Backlog in 🚪🔁 The Portal Loop Oct 4, 2023
@gfanton
Copy link
Member

gfanton commented Dec 6, 2023

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
Copy link
Member Author

moul commented Dec 6, 2023

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
Copy link
Contributor

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

@moul
Copy link
Member Author

moul commented Dec 7, 2023

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
Copy link
Member

thehowl commented Dec 21, 2023

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
Copy link
Member

gfanton commented Dec 22, 2023

@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.

@gfanton gfanton closed this as completed Dec 22, 2023
@github-project-automation github-project-automation bot moved this from Backlog to Done in 🚪🔁 The Portal Loop Dec 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🌟 Wanted for Launch
Status: Done
Development

No branches or pull requests

5 participants