To clarify the go compiler toolchain is a trivial tree. Compared to most other mainstream languages and compilers, it's not scattered to different subtrees. I believe quite some effort went into that to stay that way. When using the go compiler toolchain some directories are used for caching compiler artifacts. (You could easily delete all of these files between compiling sessions, you'll still be able to compile everything again. Though only a very space constrained environment would require such a peculiar workflow.)
If you are a go programmer the subtrees you set explicitly are 100% managed by the toolchain, there is no _need_ to ever look at them. Please note, that if you set them explicitly and with that you inadvertently mix and match different versions of go toolchain binaries and cached artifacts you'll most probably run into issues you don't want to have. Sure the environment variables can be set differently, if you have special requirements (maybe you don't have enough space on the same device). Sorry I wasn't clear: I tried to ask for these special requirements. To rephrase and clarify my original question: besides "Paths in symmetry with the environmental variables" why is it valuable to rearrange the subtrees for your use case? What are your requirements/issues you came up with a solution for? To help with your original question, assuming your only goal is to manage all subtrees exposed by environment variables "go env" shows at least 3 more trees you might want to set (GOMODCACHE, GOTOOLDIR, GOTMPDIR.) On 12/9/20, Dumitru Ungureanu <itmit...@gmail.com> wrote: > Yes, there is no requirement to manage the envvars. I personally believe > there is a requirement to know about them, though. > I read the installation doc, I think there's a hang up on your part on this > > one. > The default go tree is scattered different places, beside the obvious > trivial tree you're mentioning. > I'm arranging all the paths in a single place and I harmonize the paths > with the envvars. > Maybe you're missing the whole point I'm making in this blog post? > https://mitflit.ro/blog/golang-paths-of-mitflit/ > > On Tuesday, December 8, 2020 at 10:47:27 PM UTC+2 Gergely Födémesi wrote: > >> There is no requirement to manage these variables or to know about them, >> even if you don't use the installer. >> >> I never use the installer and I've never needed to check on those >> environment variables. >> >> (The installation documentation is short and complete, maybe you should >> check it out again.) >> >> The installed go compiler is really just a trivial tree. >> >> On Tue, Dec 8, 2020, 17:38 Dumitru Ungureanu <itmi...@gmail.com> wrote: >> >>> I don't use an installer. I set GOROOT/bin manually. And the rest >>> follows. Easy to remember, nothing to forget. >>> >>> On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi wrote: >>> >>>> On 12/8/20, Dumitru Ungureanu <itmi...@gmail.com> wrote: >>>> > Paths in symmetry with the environmental >>>> > variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. >>>> GOCACHE is >>>> > go/cache, GOENV is go/env. >>>> > Bonus points: modules in go/modules. >>>> >>>> Why do you need to manage them explicitly? When do you need to look at >>>> GOROOT, GOBIN, GOCACHE or GOENV? >>>> >>>> (I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly. >>>> After modules became the default, I've never set GOPATH either.) >>>> >>>> > >>>> > On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi >>>> wrote: >>>> > >>>> >> On 12/7/20, Dumitru Ungureanu <itmi...@gmail.com> wrote: >>>> >> ... >>>> >> > I'm currently using this directory tree for golang. >>>> >> ... >>>> >> What do you mean when you write "golang"? >>>> >> >>>> >> Why is https://golang.org/doc/install not good enough for the go >>>> >> compiler? >>>> >> >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups >>>> > "golang-nuts" group. >>>> > To unsubscribe from this group and stop receiving emails from it, send >>>> > >>>> an >>>> > email to golang-nuts...@googlegroups.com. >>>> > To view this discussion on the web visit >>>> > >>>> https://groups.google.com/d/msgid/golang-nuts/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%40googlegroups.com. >>>> >>>> >>>> > >>>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> >>> email to golang-nuts...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/c0ed7490-800b-424e-834a-4f928be2a52en%40googlegroups.com. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2BctqrqNy6PgYXEoddrNz60XOZk0jtF%2Bv3Vp%2BZ7G_PxF9yQTMA%40mail.gmail.com.
