Personally, as someone who doesn't write Go but occasionally tries to compile Go projects, GOPATH/GOROOT caused me problems all of the last 3 or 4 times that I tried to compile a Go project, and I struggled to find clear explanations of what they should be set to. I felt like I was being stupid, and I'm sure I should have read the documentation better, but nevertheless, there's my data point.
Indeed that was a problem for many people and a key motivating factor to deploy the new go modules approach (which is enabled by default for a while now). Most of the projects out there now contain a go.mod file.
That said there may still be projects out there that are unmaintained or the author didn't bother to convert to go.mod, so you might occasionally still encounter GOPATH.
That's aggravating the problem. No only the original way was painful, but now there are multiple ways and to the newcomer that just needs to contribute to a project - it's all one big mess.
Agreed! I pick up Go a few times a year (which doesn't help, admittedly) and even consulting the official documentation, it's hard for me to figure out what the current, correct way of doing things is.
Dedicate 30m to read https://blog.golang.org/using-go-modules and try it out with a small demo project,e.g. write a small tool that emits a uuid; keep the toy project very small so you don't encounter other problems that might distract you from learning the basics of dependency management.
I can understand GOPATH, but why would GOROOT cause you any problems. I think you needed to set it way back in the go 1.3 days or something, but it's been a more or less hidden thing for a long time now.
Comments
Personally, as someone who doesn't write Go but occasionally tries to compile Go projects, GOPATH/GOROOT caused me problems all of the last 3 or 4 times that I tried to compile a Go project, and I struggled to find clear explanations of what they should be set to. I felt like I was being stupid, and I'm sure I should have read the documentation better, but nevertheless, there's my data point.
Indeed that was a problem for many people and a key motivating factor to deploy the new go modules approach (which is enabled by default for a while now). Most of the projects out there now contain a go.mod file.
That said there may still be projects out there that are unmaintained or the author didn't bother to convert to go.mod, so you might occasionally still encounter GOPATH.
That's aggravating the problem. No only the original way was painful, but now there are multiple ways and to the newcomer that just needs to contribute to a project - it's all one big mess.
Agreed! I pick up Go a few times a year (which doesn't help, admittedly) and even consulting the official documentation, it's hard for me to figure out what the current, correct way of doing things is.
If you want to learn this my suggestion:
Dedicate 30m to read https://blog.golang.org/using-go-modules and try it out with a small demo project,e.g. write a small tool that emits a uuid; keep the toy project very small so you don't encounter other problems that might distract you from learning the basics of dependency management.
Search for dependencies using pkg.go.dev.
Either that or break backward compatibility. Pick your poison
I can understand GOPATH, but why would GOROOT cause you any problems. I think you needed to set it way back in the go 1.3 days or something, but it's been a more or less hidden thing for a long time now.