For a long time, Golang provides an extremely simple dependency management model. It just depends on Git repos and actually its
If you have experience on concepts and tools like monorepo/Gerrit, you can easily get the point why it was initially designed including
GOPATH. That is because Google uses monorepo.
There are some advantages claimed1 and Golang’s dependency management could work on that well.
However, monorepo does not dominate the world, which leads to lots of issues:
mastermakes breaking change, it breaks build.
To make it easier, there are some efforts:
By these tools, we may handle vendors better. But these tools are not officialy supported and it needs commit all vendor packages to repository! Can you imagine a frontend or Node.js project commits its
node_modules? This is ridiculous.
I don’t know the decision process, but Golang team finally launched Go Module in 1.11, which embraces the non-monorepo part of the world.
GOPATH, and now we can clone to anywhere.
go getinside a repo is not global, it works only at local.
go.modwith git tags, commit hashes, and semver.
Enable Go Module, edit
Initialize Go Module
go mod init .
go mod tidy
go get github.com/crispgm/go-g
go get -u github.com/crispgm/go-g
go get -u
go get github.com/crispgm/go-g@master go get firstname.lastname@example.org go get github.com/crispgm/go-g@617f32e
go mod vendor
I highly not recommend this, since getting rid of vendor is one of the major advantages of Go Module.
One of our in-house library depends on satori/go.uuid, with traditional
go get it means depend on
master. But Go Module got the latest tag by default. So the solution should be:
go get -u github.com/satori/go.uuid@master
Add the following to
go.mod to solve the trouble.
replace github.com/ugorji/go v1.1.4 => github.com/ugorji/go/codec v0.0.0-20190204201341-e444a5086c43
Go Module is not a silver bullet, and it is more a compatibility than a fix. But for me, it is great improvement.