Everything you wanted to know about GOPATH and GOROOT

Despite the fact that Go is considered one of the easiest to enter languages, we regularly hear: "somehow everything is not clear, some variables GOROOT and GOPATH need to be set." And although the topic is fully disclosed on the official Go website, it will not be more than easy to explain.

TL; DR


Now a little more:

GOROOT

GOROOT is a variable that indicates where, in fact, the entire Go build of the binary and the source codes lie. Something like JAVA_HOME. You need to set this variable with handles only in those cases if you put Go under Windows not using an MSI installer, but from a zip archive. Well, or if you want to keep several versions of Go, each in its own directory.
')
Previously (before Go 1.0) this variable was needed - it was used by the build scripts, as well as GOARCH and GOOS. But after Go 1.0, the go tool's internal logic changed a bit and now the GOROOT value is hardcoded at the build or installation stage. Ie, go - default installed - knows this value and so. It can be viewed using the command:

go env GOROOT 

On MacOS X, this is / usr / local / go /, on Linux, too (although it may depend on the distribution), on Windows, C: \ Go.

GOPATH

But the variable GOPATH is very important and necessary and it must be set necessarily, but only once. This is your workspace, where the code and binary files of everything you will be working with in Go will lie. Therefore, choose the way that is convenient for you and save it to GOPATH. For example:

 export GOPATH=~/go export GOPATH=~/gocode export GOPATH=~/Devel/go export GOPATH=~/Projects/go 

Well, be sure to save it in .profile or how you save variables there:

 echo "export GOPATH=~/go" >> ~/.profile ( .bash_profile) 

All do it once and forget. Create only this directory if it is not already there, and that’s it. Now, any call to go get github.com/someuser/somelib will automatically download the source code in $ GOPATH / src, and add the binary compilation result to $ GOPATH / pkg or $ GOPATH / bin (for libraries and executable files, respectively).

PATH

This is optional, but it is also advisable to do it right away, since you took up the setting of the environment. Sooner or later you will want to use some Go-programs that will lie in your GOPATH / bin. To use them without unnecessary gestures, add the $ GOPATH / bin directory to the PATH:

 export PATH=$PATH:$GOPATH/bin 

The go install command builds and installs the binary exactly in this directory, so this is for convenience only.

Workspace structure

Now let's look carefully at the structure of the GOPATH directory. Take an example from the official documentation:

 bin/ hello #  hello pkg/ linux_amd64/ #           github.com/user/ stringutil.a #     stringutil src/ github.com/user/ hello/ hello.go #    hello stringutil/ reverse.go #    stringutil 

Simple enough, right? It is important to understand that nobody obliges to call directories in src / by some format. You can use src / test / my_first_app / main.go and src / anyname / main.go - but if you are working with version control systems (and you are still working)), then you will undoubtedly become comfortable - go get / install utilities use These are naming conventions to make working with version control systems shamelessly simple.

Additionally

The variable GOPATH is similar to the standard PATH - you can specify several directories, through ':'. GOPATH = ~ / go: ~ / other_workspace. This is very rarely useful (for example, for working with external dependency managers like gpm), but in 99% this is not necessary, and it is recommended to use only one directory in GOPATH.

In the end, if you need separate workspaces, you can always replace the GOPATH variable with the desired one (in the build script, for example). So, in fact, do.

Links

golang.org/doc/install
golang.org/doc/code.html
dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really