It so happened that developers who are just starting to get acquainted with Go often encounter the problem of choosing a working directory for Go projects. So in the chat of the GolangConf conference this question was also asked. New gophers often scare each other with the words GOPATH and GOROOT . However, in the quick start guides with the current version of Go (1.13), these two “scary” words are not mentioned at all.
Let's see why. For the purity of the experiment, I deployed fresh Ubuntu to a virtual machine and installed Go according to the instructions from the Wiki :
sudo add-apt-repository ppa:longsleep/golang-backports sudo apt-get update sudo apt-get install golang-go
Go 1.13 is installed and ready to use:
$ go version go version go1.13 linux/amd64 $ which go /usr/bin/go $ whereis go go: /usr/bin/go /usr/lib/go /usr/share/go /usr/share/man/man1/go.1.gz
GOROOT
About GOROOT has already been perfectly written in the article of 2015 , and this information is still relevant.
It's funny that among the list of directories issued by the last command ( whereis go ), GOROOT is actually not:
$ go env GOROOT /usr/lib/go-1.13
So, for example, if for the IDE I need to specify the path to the files of the standard Go library, I will specify /usr/lib/go-1.13 . Perhaps, in this scenario, the use of GOROOT in everyday life ends.
GOPATH and modules
It would seem that in this place you need to rush to install GOPATH , but I will not do this. Actually GOPATH already set:
$ go env GOPATH /home/elena/go
I'm comfortable with the GOPATH in ~/go , which means I won’t change it.
I will immediately create a directory for my first project on Go. This can be done anywhere, for example, right in your home directory. Also, I will immediately start working with the Go Modules tool:
$ mkdir ~/hello $ go mod init github.com/rumyantseva/hello go: creating new go.mod: module github.com/rumyantseva/hello
For the go mod init command, I specified a unique module module path for my project. If necessary, a proxy or other tool will be able to find my project files along this path.
After calling the go mod init command, the go mod init directory appeared in my home directory:
$ tree ~/go /home/elena/go └── pkg └── mod └── cache └── lock 3 directories, 1 file
In this case, the lock-file (at the very bottom of the tree) is still empty.
The go.mod file appeared in the ~/hello go.mod with the following contents:
module github.com/rumyantseva/hello go 1.13
It is in go.mod that all information about the dependencies of my module will subsequently be stored.
Let's now write an application using an external dependency. In the ~/hello directory, I create the main.go file and write the following code into it:
package main import ( "github.com/sirupsen/logrus" ) func main() { logrus.Info("Hello, world!") }
Of course in real life for writing "Hello, world!" logrus can be dispensed with, but in this example, this library will help us find out where external dependency files are stored.
I launch the application in the simplest way:
$ go run main.go go: finding github.com/sirupsen/logrus v1.4.2 go: downloading github.com/sirupsen/logrus v1.4.2 go: extracting github.com/sirupsen/logrus v1.4.2 go: downloading golang.org/x/sys v0.0.0-20190422165155-953cdadca894 go: extracting golang.org/x/sys v0.0.0-20190422165155-953cdadca894 go: finding golang.org/x/sys v0.0.0-20190422165155-953cdadca894 INFO[0000] Hello, world!
Before the application was built and launched, the go mod tool worked. He defined my external dependency github.com/sirupsen/logrus , took its latest version v1.4.2 at the moment and went for transitive dependencies.
A line with a description of the dependence on logrus added to the logrus :
module github.com/rumyantseva/hello go 1.13 require github.com/sirupsen/logrus v1.4.2 // indirect
The go.sum file also appeared, which in addition to the logrus dependency logrus contains information about the hashes of transitive dependencies:
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ= github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= github.com/sirupsen/logrus v1.4.2 h1:SPIRibHv4MatM3XXNO2BJeFLZwZ2LvZgfQ5+UNI2im4= github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE= github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs= golang.org/x/sys v0.0.0-20190422165155-953cdadca894 h1:Cz4ceDQGXuKRnVBDTS23GTn/pU5OE2C0WrNTOYK1Uuc= golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
Where is the dependency code itself? It can be found in ~/go/pkg/mod . Also, checksums and other overhead information for working with dependencies will be stored in ~/go/pkg .
If you've already come across the go get tool, you know that when pulling dependencies, it actually clones the repositories (for example, in the case of git with git clone ). But go mod doesn't work that way. For go mod main unit of code is the module. Modules are archives. When working with go mod dependencies, it explicitly (if you invoked the go mod download command) or implicitly (if you started compiling the application) downloads and unpacks archives via GOPROXY . Let's see how the proxy is set in Go 1.13 by default:
$ go env GOPROXY https://proxy.golang.org,direct
So, as a proxy when building my "Hello, World!" used by proxy.golang.org . Of course, this variable can be changed by choosing a different repository of modules. For example, you can deploy your own internal proxy company, which will be stored, including internal libraries, the code of which was not published in open source.
In general, if I am starting a new project and do not mind using Go Modules, I may not know anything about GOPATH . Go will create the ~/go directory on its own when it is needed.
When is GOPATH needed?
If you basically do not use Go Modules (for example, in a legacy project), getting away from more explicit work with GOPATH may not be so simple.
To see what will happen to my project, if I decide not to use go mod , delete the files ~/hello/go.mod and ~/hello/go.sum . I will also remove ~/go to return to the state of the system that I had at the very beginning:
rm -rf ~/go ~/hello/go.mod ~/hello/go.sum
Only the main.go file remains in the ~/hello main.go . What happens now if I try to run it with go run ?
$ go run main.go main.go:4:2: cannot find package "github.com/sirupsen/logrus" in any of: /usr/lib/go-1.13/src/github.com/sirupsen/logrus (from $GOROOT) /home/elena/go/src/github.com/sirupsen/logrus (from $GOPATH)
Here they are, these scary GOROOT and GOPATH :)
In order to compile the application, I need to pull up the dependency in GOPATH . I do this with the good old go get :
$ go get -v github.com/sirupsen/logrus github.com/sirupsen/logrus (download) created GOPATH=/home/elena/go; see 'go help gopath' get "golang.org/x/sys/unix": found meta tag get.metaImport{Prefix:"golang.org/x/sys", VCS:"git", RepoRoot:"https://go.googlesource.com/sys"} at //golang.org/x/sys/unix?go-get=1 get "golang.org/x/sys/unix": verifying non-authoritative meta tag golang.org/x/sys (download) golang.org/x/sys/unix github.com/sirupsen/logrus
What happened First of all, go get created the ~/go directory (the one specified as GOPATH ). Then the process of cloning the repositories with dependencies began. It's funny that cloning repositories looks noticeably slower than the option when we used go mod to download and unpack modules. However, the dependency code can now be found inside ~/go/src/ .
By the way, there was still no git client on my clean Ubuntu installation, and in order for go get work, I had to install it.
I launch the application:
$ go run main.go INFO[0000] Hello, world!
Works!
That's just at the application level, I now do not track the version of external dependencies. What if, due to a vulnerability, at some point in the github.com/sirupsen/logrus repository is not the logger I expected, but some malicious code? Sooner or later, I still need a tool for working with dependencies, and if Go Modules for some reason does not fit, you have to look for something else ...
Conclusion
This article did not address some specific points, and working with external dependencies in Go can still cause a lot of questions. However, new versions of Go at least do not impose restrictions on where the working directories of your projects can be created.
If you are starting a new project, try Go Modules! Reverting to the old approach to working with dependencies makes sense only if something goes wrong. By the way, if you prefer to store all the dependencies inside the project, Go Modules supports vendor mode.
If you need to work with an existing project, and for some reason you do not want to translate it into Go Modules, it is important to indicate the features of its deployment and dependency management in the project documentation. If newcomers unfamiliar with the old approaches to working with dependencies come to the project, it will be much easier for them to deal with the project if all the documentation is in place.
By the way, on October 7th at the GolangConf conference, as one of the special activities, we are planning an expert zone where anyone can ask any questions about Go to members of the conference program committee and enthusiasts of the Russian Go-community. Install Go? Deal with addictions? Write a microservice? This is for us!