Menu
By default, Go pulls imported dependencies by grabbing the latest version in master (github) or default (mercurial) if it cannot find the dependency on your GOPATH. And while this workflow is quite simple to grasp, it has become somewhat difficult to tightly control. Because all software change incurs some risk, I'd like to reduce the risk of this potential change in a manageable and repeatable way and avoid inadvertently picking up changes of a dependency, especially when running clean builds via CI server or preparing to deploy.
What is the most effective way I can pin (i.e. lock down or capture) a package dependency so I don't find myself unable to reproduce an old package, or even worse, unexpectedly broken when I'm about to release?
---- Update ----
Additional info on the Current State of Go Packaging. While I ended up (as of 7.20.13) capturing dependencies in a 3rd party folder and managing updates (ala Camlistore), I'm still looking for a better way...
Here is a great list of options.
Also, be sure to see the go 1.5 vendor/ experiment to learn about how go might deal with the problem in future versions.
769
As of Go 1.11, the go command (go build, go run, and go test) automatically checks and adds dependencies required for imports as long as the current directory or any parent directory has a go. mod.
For installing the go project dependencies, we use go get command, which automatically updates the go. mod file. You can also install go project dependencies by following a few steps, but remember as the package is still not used anywhere in the project it will be marked as indirect.
To install dependencies, use the go get command, which will also update the go. mod file automatically. Since the package is not currently used anywhere in the project, it's marked as indirect. This comment may also appear on an indirect dependency package; that is, a dependency of another dependency.
You might find the way Camlistore does it interesting.
See the third party directory and in particular the update.pl and rewrite-imports.sh script. These scripts update the external repositories, change imports if necessary and make sure that a static version of external repositories is checked in with the rest of the camlistore code.
This means that camlistore has a completely repeatable build as it is self contained, but the third party components can be updated under the control of the camlistore developers.
69
There is a project to help you in managing your dependencies. Check gopack
25
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
