Go GOPATH Issues
The cluster focuses on frustrations with Go's GOPATH workspace model, including its rigid directory structure for multiple projects, workarounds like per-project GOPATHs and tools such as gpm or Glide, and the transition to Go modules that eliminate GOPATH requirements.
Activity Over Time
Top Contributors
Keywords
Sample Comments
But I have tools built with GOPATH assumptions...
Multiple unrelated Go projects in different GIT/SVN repositories. GOPATH experience is painful.
Have they fixed already the GOPATH crap?
You're welcome to clone the repo yourself and build it. Go doesn't have a centralized package manager like npm, just a tool that automates downloading and building a repo. Nobody is forcing you to use it; it's a convenience.
The intellij go plugin is your friend. Per project go-paths. It's also a good use of make.
Seems like the author is suggesting something very similar to what [gpm][1][2] provides. I use gpm for a few projects, along with a makefile that creates a GOPATH at $(pwd)/_build, and it works fairly well.[1]: http://java.dzone.com/articles/why-gpm-right-go-package[2]: https://gi
You may want to consider looking into go modules. It works much the same way that cargo does for rust and you won’t need to worry about GOPATH for most cases.
Is the GOPATH bullshit gone already?
Curious if this is tightly wedded to $GOPATH, which thankfully seems to be dying with Go modules.
IMHO, fixing it would be being able to build go code on random directories without env hackery.