Open moul opened 9 months ago
Based on today's discussion, I have officially relocated the main binary, gno
, to gno.land/
. This move positions it as the ecosystem's primary binary.
Additionally, I have introduced a new binary called gnolang
. Similar to gnokey
, it is a minimal composable binary along with its library. This allows for the composition of binaries for various purposes. Importantly, it enables us to maintain the independence and testability of gnovm
without any external dependencies.
To clarify, while I personally prefer using only the gno
binary, we can propose a way for forkers and builders to quickly get started with the gnolang
binary. Meanwhile, we can continue developing integration tests and other components in gnovm/
that are separate from the rest of the project.
Edit: bonus, what do you think about keeping the structure mentioned above, but also.... create a top-level main.go file to install the gno
binary with go install github.com/gnolang/gno
?
Edit: bonus, what do you think about keeping the structure mentioned above, but also.... create a top-level main.go file to install the
gno
binary withgo install github.com/gnolang/gno
?
I like this!
The OP also looks good to me. A few further proposals/q's:
/pkg/
from tm2
(unless we plan to add commands to tm2
)gnosdk/pkg/codegen
should also contain, for instance, #814's genstd
?fooland
, why do they use it, how do they use it?GNO:
gno key
for convenience, but gno
is not blockchain aware.GNOLAND:
GNOKEY:
And I would suggest renaming GNOSDK to GNOLANDTOOLS, for any chain based on the GNO VM.
@jaekwon
gno key
then just run gnokey
with os/exec?I'm not sure if I remember everything we discussed during the call, but here are the key points:
gno
within gnovm/
and avoid incorporating blockchain features.gnoland
, gno
, gnokey
, etc., should remain minimal. However, this doesn't mean we can't have helpers and flows. Let's create a top-level folder called "gnolandtools" (I dislike the long name) for things like creating flows using multiple Unix-style commands or including functionalities that we don't want to include in the minimal binaries. Essentially, it's similar to what I previously referred to as "gnosdk," but with a new name. For example:
gno mod-publish
(#743)
gno mod
into its own git-style subbinary? I think so.Edit: If it's not gnosdk/
and since I don't like gnolandtools
, what are your thoughts on using github.com/gnolang/tools/gno{,land}-xxx
instead? In this case, xxx
represents a folder that contains a specific tool, such as tools/gno-mod
, tools/gno-dev
, tools/gno-publish
, and tools/gnoland-monitoring
.
See #1256
So:
cmd/gno
does not recognize a sub command, try to find gno$command
in path. (allows for gno key
)exec
'ing them.gno dev
can be implemented as a gnodev
binary that merges things together.contrib
directory contains "community contributions", and as such many useful commands and extensions to gno
which are useful for development (but not part of the "core" gno binaries).Is this roughly our current position? @moul
I think we should have only one of misc
or contrib
.
Is this roughly our current position? @moul
Yeah, that’s the idea.
For the Git method, let's hold off and have users specifically use "gnodev" rather than "gno dev." We might consider enabling "gno$command" execution later on.
I think we should have only one of misc or contrib.
I favor flagging 'contribs/gno*/' directories for binaries, similar to '/usr/local/bin', and using 'misc' for everything else, possibly with subdirectories, akin to '/opt' — assuming I've got the Unix standard folders right.
Added to the Rouen Retreat board. I think a greater discussion on the strategy and writing out a document on what we want for binary/repo structure might be good :)
Please note that the comments should be read. The body of this issue is not yet updated with the latest decisions.
This issue seeks to clarify concepts and suggest future updates, related to #1105, where I proposed a
gnosdk
space.The
gno.land/cmd/gno
andgnosdk
should focus on user experience, while the rest ofgno.land
,gnosdk
, andtm2
should showcase standalone binaries and minimalist libraries.The main binary,
gno.land/cmd/gno
, should be the developers' go-to binary in the ecosystem, catering to both developers and non-developers. Consideringgno.land
's significant role with github-style realms, IBC, and ICS features, it's fitting to house the ecosystem binary,gno.land/cmd/gno
, here, even if it extends beyondgno.land
.gnoland
, designed for production runtime management and daemon operation, should remain minimalist, focusing on node initiation and network joining, leaving extensive configuration and management tools tognosdk
orgno
under anode
/genesis
subcommand.The
fooland
binary, aligning with other cosmos chains, serves as a central hub, combining standalone libraries/binaries into one. Once established, the secondary binary, "gno," becomes necessary, allowing "fooland" to focus on unique features and enabling gnolang developers to use standard ecosystem tools.I support including basic account management and client functionality in the
gno
binary, reducing the need forgnokey
, except for demonstrating a minimal client for a new chain.Proposal for structural target:
In bold, the things that are not existing yet.
gno.land
pkg
gnoland
: a node app for gno.landcmd
gnokey
: a standalone minimal client for gno.landquery
,maketx
, etc. (client functionality)list
,create
, etc. (account management)gnoland
: a standalone minimal production node for gno.landstart
reset
(WIP)gnoweb
: a standalone minimal production gnoweb for gno.landgno
: the main binary for the gno ecosystem (moved fromgnovm/cmd/
)test
,build
,doc
, etc.: Go-like commands for gno; I suggest we switch fromgno.Machine
tognovm.Keeper
genesis
: tools for manipulating the genesis of gno.landnode {backup,restore}
: new place for gnotxportnode stats
,...: other helpers related to node managementdev
: an opinionated shortcut to run a single gnoland node + gnoweb in memory/diskgnovm
pkg
gnolang
: currentgnolang/gno.Machine
commands
: composable CLI commands, equivalent oftm2/keys/client
cmd
gnolang
: new binary with blockchain-lessgno.Machine
commands (most of today'sgno
binary)gnosdk
pkg
genesis
: a library for manipulating the genesiscodegen
: helpers for code generation in the gno ecosystemcmd
fooland
: a unified library with gnokey, gnoland, gnotxport, etc. to run a foo.land node or interact with itquery
,maketx
: gnokey's client functionalitylist
,create
: gnokey's account managementnode
start
: start gnolandtxport
: backup and restore functionality from gnotxport to gno nodegenesis-flows-such-as-POS-coordination
web
: gnowebfaucet
: gnofaucettm2
pkg