For those of you newer to Go, it might surprise you to know that go modules was not always part of the language. When Go launched in 2009, it did not have any dependency management solution as Google had no need for one.

A Brief History of Dependency Management in Go

As Go matured over the years, its approach to dependency management has evolved, reflecting both the community’s needs and the language’s philosophy. Here’s a brief look at how we got to Go Modules.

  1. No Official Tool (Early Days): In the earliest days of Go, there wasn’t an official tool for dependency management. Developers were left to their own devices, often resorting to vendoring—copying the source code of dependencies directly into their projects. This method was simple but could lead to issues with versioning and bloated repositories.

  2. GOPATH and the Workspace Model: Early on, Go developers organized their code and dependencies in a specific directory structure. We would settle env var GOPATH to be the root of our dev folder, and all imports in other projects would be relative to this. While GOPATH provided some structure, it lacked versioning, leading to the “diamond dependency problem” where different projects required different versions of the same package.

Diamond Dependency Problem

  1. godep, glide, and govendor Recognizing the limitations of GOPATH, the Go community developed various tools like godep, glide, and govendor. These tools helped specify and lock versions of dependencies. They represented the community’s efforts to find a robust solution to the challenges posed by GOPATH and dependency management generally.

  2. dep - The official Experiment: As the need for a standardized tool became clear, the Go team introduced dep as an official experiment. dep provided both a manifest (Gopkg.toml) and a lock file (Gopkg.lock), allowing precise control over dependencies and versions. Dep was actually run as another project and not part of the golang repo. You can explore it here: https://github.com/golang/dep

  3. Go Modules and the Rise of go mod: With Go 1.11, Go modules were introduced as an opt-in feature. Modules allow for versioning of Go packages, making it easier to specify and use dependencies outside of the GOPATH. The go mod suite of commands, including `go get, offers a streamlined toolset for dependency management. By Go 1.13, modules became the official recommendation, signaling the end of the GOPATH era.

The rest they say, is history :)