Ramblings of an aging IT geek
← Ramblings of an aging IT geek
golang

throwing out dep and letting go modules do its job

Migrating a Go service off dep and Gopkg.toml onto go modules, and finding the transition far less dramatic than the years of vendoring drama had led me to expect.

A terminal with Go source on screen

I have been putting this off. The service still carried a Gopkg.toml, a Gopkg.lock and a fat vendor/ directory, all faithfully managed by dep, which has been on life support for a while now and is firmly in maintenance-only mode. With modules being the default since 1.13 there was no longer any excuse, only inertia.

The migration was almost insultingly quiet. From the repo root:

go mod init github.com/jmylchreest/thing
go mod tidy

go mod init read the existing Gopkg.lock and seeded go.mod with sensible versions, then go mod tidy walked the imports and filled in the rest. A few transitive dependencies got pinned slightly differently than dep had them, so I diffed the resolved versions against the old lock before trusting it, but nothing actually broke.

The bits I expected to fight, I didn't. The bit I didn't expect to think about was vendoring. I deleted vendor/ entirely, because modules cache globally now and CI can fetch on demand. If you genuinely want it back, go mod vendor rebuilds it and -mod=vendor uses it, but for this service the cache was fine.

dep served me well for a couple of awkward years. It is just nice to delete two TOML files and a vendor tree and have the toolchain handle the thing the toolchain should always have handled.