Welcome, Go modules - part1
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…
Makefiles pre-1.0
In the beginning, there were Makefiles such as
these, scripts, maybe a 🧙 and lots of
GOPATH 1.0
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 test,
go build, etc. use GOPATH to resolve imports.
vendor dir,
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.
Community-driven dependency managers
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.
Go modules, 1.11 1.12
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
vgo1, ignore it, do a mental conversion for go modules (available with go versions 1.11 or higher).
Key concepts:
- semantic versioning + import compatibility rule = semantic import versioning
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.
- introduces the env variable
GOPROXY - got in early, check out the athens project, a proxy server. It’s likely other big players will follow.
- introduces the env variable
- For brevity,
vgowas an experimental (forked) version of Go that brought us an early implementation of Russ's proposal. As I write this, go1.11beta2 is released and has experimental support for Go modules. You should now usego1.11or higher. ↩