The Golang dependency story continues to grow more "official" solutions, which means it's time to re-evaluate whether or not dep is still the best available option.
go mod
In the most recent stable Go version (v1.13+), Go modules have finally hit stable and are now the default way that Go resolves $GOPATH calculation. This also provides a basic mechanism for declaring code dependencies and their versions (accessible via the go mod subcommand, or by editing the go.mod file), without the need to vendorize 3rd-party code (as dep and glide both do). This should help in a couple of important ways:
No more dependency upgrade changesets that obscure actual 1st-party source changes; with Go modules, a dependency upgrade should only manifest itself as a change to the go.mod file
Improved support for alternative source code repository structures (though being honest, I'm quite happy with the "legacy" style file system layout constraints)
Improved support for module forks and import paths for forks of dependencies; this has been a long-running problem with vendorizing dependency management systems, as these typically encode the fully-qualified repository name (e.g. github.com/[OWNER]/[REPO]) in the directory structure itself, causing issues when a new [OWNER] forks the repository
Context
The Golang dependency story continues to grow more "official" solutions, which means it's time to re-evaluate whether or not
depis still the best available option.go modIn the most recent stable Go version (v1.13+), Go modules have finally hit stable and are now the default way that Go resolves
$GOPATHcalculation. This also provides a basic mechanism for declaring code dependencies and their versions (accessible via thego modsubcommand, or by editing thego.modfile), without the need to vendorize 3rd-party code (asdepandglideboth do). This should help in a couple of important ways:go.modfilegithub.com/[OWNER]/[REPO]) in the directory structure itself, causing issues when a new[OWNER]forks the repository