You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A common refrain on the Go mailing list is "don't use GOROOT". It is good advice, GOROOT leads to confusion.
However, right on the Go download page, https://golang.org/doc/install, users are instructed to set a GOROOT: "In this case you must set the GOROOT environment variable to point to the directory in which it was installed."
I sometimes give users alternate instructions about how to use a copy of the binary toolchain they just downloaded as GOROOT_BOOTSTRAP to rebuild the toolchain in its new location, so that setting GOROOT is not necessary. But this is several extra steps of work that are mysterious to a new Go user.
As an alternative, Go 1.8 introduced os.Executable. The cmd/go binary could use this to find its own GOROOT, and do the right thing by default if the distribution is installed to an unusual location.
A common refrain on the Go mailing list is "don't use GOROOT". It is good advice, GOROOT leads to confusion.
However, right on the Go download page, https://golang.org/doc/install, users are instructed to set a GOROOT: "In this case you must set the GOROOT environment variable to point to the directory in which it was installed."
I sometimes give users alternate instructions about how to use a copy of the binary toolchain they just downloaded as GOROOT_BOOTSTRAP to rebuild the toolchain in its new location, so that setting GOROOT is not necessary. But this is several extra steps of work that are mysterious to a new Go user.
As an alternative, Go 1.8 introduced os.Executable. The cmd/go binary could use this to find its own GOROOT, and do the right thing by default if the distribution is installed to an unusual location.
WDYT? @rsc @ianlancetaylor
The text was updated successfully, but these errors were encountered: