This commit migrates away from the now-unsupported dep dependency management tool to using Go's
v1.11+ modules. This should also hopefully simplify dependency management going forward for us,
especially by avoiding awkward vendorization commits.
Resolves #21
Go modules
Go modules generally work in a similar fashion to Python's and Node's package/module systems:
go.mod (i.e. requirements.txt/package.json) is the module definition itself, including all of the dependencies our module relies on
go.sum (i.e. pip freeze/package.lock) is the "frozen" list of direct + transitive dependencies computed by the go.mod file, with snapshots of their corresponding go.mod file hashes
One nice thing is that the go mod <CMD> CLI doesn't need to be explicitly invoked for each new dependency, but instead can auto-detect dependencies from the import ( ... ) statements in the source code. So to add a new dependency, all you need to do is import it in your file, and then run go mod tidy to ensure that our go.mod + go.sum files pick up any new dependencies. The same process also applies for removing unused dependencies.
Another note that is probably very obvious from this diff is that with Go modules, we no longer need to vendorize the external dependencies into tilenol's codebase. This should certainly make future dependency change diffs much easier on the reviewer's eyes.
Miscellaneous
One minor note is that we had to bump the version of our YAML parser dependency from v2 to v3, as it looks like there are some issues with v2 in the Go module world. That said, the API looks mostly compatible (aside from a minor change to YAML strictness), so this shouldn't be too concerning.
Overview
This commit migrates away from the now-unsupported
depdependency management tool to using Go's v1.11+ modules. This should also hopefully simplify dependency management going forward for us, especially by avoiding awkward vendorization commits.Resolves #21
Go modules
Go modules generally work in a similar fashion to Python's and Node's package/module systems:
go.mod(i.e.requirements.txt/package.json) is the module definition itself, including all of the dependencies our module relies ongo.sum(i.e.pip freeze/package.lock) is the "frozen" list of direct + transitive dependencies computed by thego.modfile, with snapshots of their correspondinggo.modfile hashesOne nice thing is that the
go mod <CMD>CLI doesn't need to be explicitly invoked for each new dependency, but instead can auto-detect dependencies from theimport ( ... )statements in the source code. So to add a new dependency, all you need to do isimportit in your file, and then rungo mod tidyto ensure that ourgo.mod+go.sumfiles pick up any new dependencies. The same process also applies for removing unused dependencies.Another note that is probably very obvious from this diff is that with Go modules, we no longer need to vendorize the external dependencies into tilenol's codebase. This should certainly make future dependency change diffs much easier on the reviewer's eyes.
Miscellaneous
One minor note is that we had to bump the version of our YAML parser dependency from
v2tov3, as it looks like there are some issues withv2in the Go module world. That said, the API looks mostly compatible (aside from a minor change to YAML strictness), so this shouldn't be too concerning.