gno env (GNOROOT, GNOPATH)

[moul]

Note: The proposal has been discussed in the comments below. The body will be updated with the final decision.

Let's enhance our command-line interface by introducing a new subcommand: gno env. This subcommand should initially support at least two environment variables: GNOROOT and GNOPATH.

Our primary target is a production environment where GNOROOT is set to /usr/local/gno and GNOPATH to $HOME/gno. However, we should also allow for flexibility in changing this default behavior, particularly when working with a manually cloned repository.

As a next step, we could consider leveraging go build -tags to automatically set GNOROOT to the current cloned repository when using Makefile commands. This would provide a more seamless experience for developers and contribute to a more robust and flexible toolset.

I suggest including the gno env command and importable package in gno.land/{pkg,cmd}. Moreover, the roles of gnovm/ and tm2/ should be modified to receive the path during initialization instead of guessing it. This way, they won't rely on gno.land and will be independent of the environment, aligning with the principles of minimalism and simplicity. In short, apart from the unit tests, we should ensure that tm2 and gnovm do not attempt to guess paths.

[thehowl]

What's the purpose of GNOPATH?

It doesn't exist and since we already have gno.mod, I don't see much of a point.

Note that we currently have GNOHOME, but it serves a slightly different purpose (and is related to gnokey instead of just gno)

[moul]

We require a storage location for gno mod download files, in addition to configuration files.

---

New proposal:

• GNOROOT refers to the read-only clone of the standard libraries and other components.
• GNOHOME is where we store wallets, client configuration, and download dependencies using the gno mod download command. It is equivalent to $GOPATH/{src,pkg,mod} with additional configs.

I prefer using GNOPATH to align with Go's commonly used environment variables. However, we can also retain GNOHOME and prioritize using XDG_ for more hidden locations by default.

Both variables are important for proper configuration, but manual checkout should not be mandatory for either path.

I will update the top-level body to reflect the improved proposal if you agree.

[moul]

FYI, during the discussion regarding #1201, we explored the potential of eliminating those two variables altogether.

We discussed a stricter alternative, which is opaque to environment modification and therefore more consistent: to rely on go:embed for everything that is currently loaded from the file system at runtime, including stdlibs.

Currently, we have valid arguments (IMO) to support their retention:

• They facilitate work outside the main repository.
• They enable quick work on stdlibs, examples without the need to rebuild go:embed when working on stdlibs or even examples/ that are not yet go-gettable.
• They enhance the discoverability of stdlibs/examples folders for tools like gopls, editors' jump-in feature, etc.
• And we said other arguments that I don't remember, to be honest.

[gfanton]

The main advantage of go:embed for me is the ability to produce a standalone binary, especially with gnoland, which we can then distribute anywhere and have it work out of the box. go:embed is easy to add and should also be straightforward to enable/disable at build time using go build flags. However, for now, it's not suitable for our development for the reasons you mentioned. I think it is totally desirable to have; it just shouldn't be the primary default at build (at least for now).