In the beginning...

All our dependencies should live under $GOPATH

Install them with go get

But what about versioning?

Everytime we build our application, the latest version of our dependencies would be installed.

Enter Go 1.5

Go 1.5 introduced the experimental vendor feature

This means that whenever we run the go command it would look for our dependencies under ./vendor

People started building tools around that

• dep
• govendor
• glide
• godep
• gvt
• govend

All of them operated on the same principle

Describe your dependencies and their version in a manifest file

Run a simple command to download them into the vendor folder

Familiar?

Most of these tools are now deprecated and recommend using go modules

govendor glide

So what exactly are go modules?

As of Go 1.11 modules are Go's new dependency management system

The go.mod file

Describes the dependencies and their versions

Managing dependencies

• go mod download - download modules to local cache ($GOPATH/pkg/mod)
• go mod tidy - add missing and remove unused modules
• go mod vendor - make vendored copy of dependencies

Dependency version can be:

• git tag (preferrably)
• git commit hash

Easier migration from one major version to another smoother

Developers are adviced to publish different modules for their different major version

This is easy, because Go modules allows to have modules in a sub-directory of other modules

Central repository trust

Along with go.mod we also have go.sum file. This contains the checksums of all our dependencies

Therefore, if we try to download a source and the repository is compromised we will know the downloaded version does not match the expected one

But what about new dependencies?

The Go team released a public registry , which will contain the checksums of all the version of all the public modules available

GOPROXY

Anothing thing which was introduces was $GOPROXY. If this environment variable is set, the modules will be downloaded from there

The Go team already released the offical Golang proxy