For those strictly interested in what is it and how do I use it? head over to part2.
I’ll skip majority of the historic bits and add a timeline for context. The path towards Go modules…
In the beginning, there were
Makefiles such as
these, scripts, maybe a 🧙 and lots of
An env variable pointing to one or more Go dirs scanned in order, first entry has highest precedence. Usually $HOME/go (default as of 1.8). Click here for more details
go get pulls and stores third party packages ($GOPATH/src). Other commands:
go build, etc. use GOPATH to resolve imports.
vendordir, 1.5 1.6
Introduced as an attempt to achieve reproducibility, availability and play nice with third party tools. Go tools use vendor dir, if present and contains .go files, to resolve imports. The vendor dir will take precedence over GOPATH to resolve imports.
There were many over the years, to list a few:
govendor, gb, glide, gom, godep, etc.
dep falls into it's own class. Briefly, it was a petri dish experiment
to better understand the problem space of package versioning and dependency management. Some hoped it would become part of the official Go tooling. It did not. No further comment outside a big thank you to all the contributors.
Dependency management baked right into Go. Introduces the concept of semantic import versioning and many other goodies for building modular software.
I cannot express how excited I am for go modules! I vividly remember Feb. 20’2018 (which also happens to be my birthday), when Russ released the Go & Versioning series, note the “shorter followup posts” section. I thought to myself, what an awesome present 🎁.
If you haven’t been following along, here are a few links to get you up-to-speed.
The initial proposal found in issue#24301.
A Proposal for Package Versioning in Go from the official blog.
From the godocs tip: Modules, module versions, and more
The wiki: Go 1.11 Modules
Open GitHub issues with modules label
If you hear the term
vgo 1, ignore it, do a mental conversion for go modules (available with go versions 1.11 or higher).
Reproducible builds are achieved by tracking dependencies in a go.mod file.
Verifiable builds are achieved with go.sum, a file that sits alongside go.mod.
Module proxy support. This one is interesting because it maintains copies of modules outside the traditional vcs, enabling, in theory, faster and more reliable builds.