Versioned Go and the future of package management

Picture by Ashley McNamara CC BY-NC-SA 4.0

Once upon a time

Go packaging and distribution has been always a problem. Since the earliest versions, Go packaging relies on a directory in the machine where all the code is placed. This directory, stored in a global variable named $GOPATH, it doesn’t only have your source code, but also all the dependencies it uses. Dependencies are added and pulled from control version systems like git using the command go get, and stored for all the projects.

This has several issues: you pull only one global version of the dependency which is shared by all the projects, and because it uses the URL of the repository as an identifier, you cannot have different versions of the same dependency. This version is also the last version available.

Different projects using the same dependency, but different versions, could not coexist in the same machine without some $GOPATH shenanigans. It also forces you to follow the code organization proposed by Go, which is trivial itself but can make many people feel unhappy about this.

The Go vendoring experiment

In response to the community complaints, on June 19th, 2015, the Go team added a flag to the Go toolchain named GO15VENDOREXPERIMENT which enabled vendoring dependencies in Go projects.

With the flag enabled and a vendor folder containing dependencies, it allowed to resolve the external dependencies using the vendor folder. For example, if you reference in your code to import github.com/foo/bar it will look for vendor/github.com/foo/bar in your file system. This experiment did not include any version resolution, version file, or even versioning tool. It was up to the community to fill the gap. The go get tool was still working as before.

The community quickly reacted creating tools like godep, glide or gb. Each tool had its own version resolution method, versions file, and workflow. This created chaos and discomfort in the community as there was no “official” tool and it was not clear the support and integrations for these experiments.

Finally, the Go team proposed an official tool named dep to deal with this instability feeling. The tool contained a versioning file, algorithm resolution, and workflow. It…