Open zivkovicmilos opened 3 months ago
I suggest we adapt our communication and guidelines to distinguish between p/
and r/
more clearly:
p/
(Pure Packages):
Render()
function, no banker, essentially read-only source code or dependencies.r/
(Realms or Apps):
Render()
function, banker, or other stateful features. Or not.p/
) as dependencies.Sure, here's an improved version of that text:
For example, you can have r/manfred/myapp
, a stateful app with banker and Render
, that includes p/avl
(a pure dependency). It can also import r/manfred/myapp/myhelpers
, which is stateless and does not use banker, making it more like a package but not pure. Additionally, you can have r/manfred/myapp/admin
, a realm where you centralize all your admin features to keep the top-level realm cleaner.
On other Gno-powered chains, this distinction might not be necessary, but on the Gno.land blockchain, we offer both source-code hosting (p/
) and app deployment (r/
).
We should update Gnoweb to reflect these differences in interfaces:
p/
: Developer-focused space, no concern for Render()
. More developer metrics.r/
: App store-like space, encouraging interaction and showcasing app features.This means you can have a single gno.mod
file in an external repo like https://github.com/moul/my-gno-app containing the top-level realm (the index of your app) and subfolders that can be sub-realms with data or just sub-packages that are technically realms but not using any realm features (persistency, banker, etc.).
It also means that I or someone else might want to import r/manfred/myapp/myhelpers
, which is possible from r/
. In such cases, it could be beneficial to add a "fork" feature that assists in converting this folder into a pure package. This would involve spending some time to make it more useful for developers by improving documentation, adding unit tests, or enhancing the API.
cc @leohhhn @zivkovicmilos @thehowl @alexiscolin
Unable to deploy module with a single top-level
gno.mod
, with multiple sub-packages withoutgno.mod
sDescription
Gno currently does not support deploying a Gno module (with a single top-level
gno.mod
) and multiple sub-packages, which a super common Go library structure:Instead, to deploy this package to the chain, each subfolder requires its own
gno.mod
, even though this is a perfectly normal scenario and structure in standard Go.Top level
gno.mod
:a.gno:
b/b.gno:
c/c.gno:
Your environment
macOS Sonoma 14.5
aa2a0da
(master
)Steps to reproduce
gnodev
against it, orgno lint
, or deploying it withgnokey
gnodev .
from the downloaded example bug foldergno lint --v .
from the downloaded example bug folderExpected behavior
The package should be deployed, even though each sub-package does not have a
gno.mod
Actual behavior
Each sub-package (folder) requires its own
gno.mod
, and these need to be referenced in the top-levelgno.mod
Logs
Running
gno lint --v .
:Gnodev:
Proposed solution
Not sure what would be the solution right off the bat.
Adding individual
gno.mod
s to each sub-folder (package), and runninggno mod tidy
from the top-level directory (which adds the requirements) fixes the problem, but this shouldn't need to happen in the first placecc @ajnavarro @gfanton @moul