Chapter 17 Modules and Dependencies on Go: Under the Hood

17.1 The Hard Parts of Dependency Management

Mon, 01 Jan 0001 00:00:00 +0000

17.1 The Hard Parts of Dependency Management

Modern software is almost never written from scratch. For an ordinary server program, one level down the import list you find a logging library, an HTTP router, a serializer; one level further down are the cryptography, compression, and network primitives that each of those depends on. The code that is actually yours may be less than one percent of the whole dependency graph. This brings the dividend of reuse, and it also brings a question that is not yours by rights yet must be answered by you: for every package in this graph, which version should you use? This section is in no hurry to give Go’s answer; first we want to make the difficulty of the problem itself clear. There are two main threads to it: one is how to choose a version (diamond dependencies and constraint solving), the other is how to keep it from drifting once chosen (reproducible builds). Only once these two are understood can you see why the “minimum version selection” scheme of 17.3 deserves its own design, and what price Go paid to get there.

17.2 Semantic Version Management

Mon, 01 Jan 0001 00:00:00 +0000

17.2 Semantic Version Management

To manage versions, we first have to make version numbers mean something. 17.1 reduced the difficulty of dependency management to two points: version conflicts in diamond dependencies, and reproducible builds across machines and across time. Whether these two can be solved depends on a more basic premise, what a version number actually promises. If the relationship between v1.5 and v1.4 were entirely unpredictable, then no selection algorithm could get started, and we would be forced back to a solver that “tries every pair of versions”. The approach Go modules take is to first turn the version number into a contract a machine can trust, and then, on top of that contract, propose one distinctive and uncompromising rule, semantic import versioning. This section makes both of these clear. They are the premise on which the version selection algorithm of 17.3 can stand, and stand simply enough to be “a single graph traversal”.

17.3 Minimal Version Selection

Mon, 01 Jan 0001 00:00:00 +0000

17.3 Minimal Version Selection

Having settled on semantic versioning (17.2), one last question remains: when different modules in the dependency graph require different versions of the same dependency, which version do we pick? Go’s answer is a counterintuitive yet remarkably concise algorithm, Minimal Version Selection (MVS). It is the most distinctive and the most thought-provoking part of Go’s module design: other package managers turned this into a problem that needs a constraint solver, while Go compressed it into a single pass over a graph. This section first lays out the rules, then looks at why it can be this simple, and finally places it back within the broader lineage of the field to see exactly what it trades away and what it gains.

17.4 The vgo versus dep Dispute

Mon, 01 Jan 0001 00:00:00 +0000

17.4 The vgo versus dep Dispute

Today’s Go Modules did not exist from the start. They were born out of a rather dramatic, and rather controversial, community episode: the vgo versus dep dispute. This history is not mere gossip. It reflects the real tension among open-source project governance, technical decision-making, and community sentiment. It is the final piece for understanding why Go Modules are the way they are today, and it is also a concentrated performance, at the toolchain level, of the design philosophy this book has been discussing all along.