Why Dependency Management?
* Let's talk about dependency mgmt in general
* What problems are we solving?
* repeatable builds
* use external code
* Examples you may have used
* bundler
* npm
* nuget
* maven
go no need dependency management!
* Commonality is ~1 tool per language/ecosystem
* google's original answer was "you don't need it"
* copy the code sillypants
I have regrets
* go has ... a few more than that
* go 1.5 added vendor, hurray!
* this is still too hard
* none of the tools work together...
* no one is tagging releases because go get discourages it
* enter dep!
* official experiment
* static analysis
* sync-based
* understands other tools config
* import graph: identifies dependencies
* manifest: controls dep
* lock: list of dependencies and their versions
* vendor: local copy of your dependencies, supercedes GOPATH
Manifest - Gopkg.toml
[[constraint]]
name = "github.com/sdboyer/deptest"
source = "http://github.com/carolynvs/deptest"
version = "0.8.0"
[[constraint]]
branch = "master"
name = "github.com/pkg/errors"
* managed by YOU
* Fun fact, dep still works when this file is empty!
* source: mirror or fork
* branch or version range
Lock - Gopkg.lock
[[projects]]
name = "github.com/sdboyer/deptest"
revision = "ff2948a2ac8f538c4ecd55962e919d1e13e74baf"
version = "v0.8.1"
[[projects]]
name = "github.com/pkg/errors"
revision = "17b591df37844cde689f4d5813e5cea0927d8dd2"
version = "v0.7.1"
What the what? Why v0.8.1 instead of 0.8.0? Where did master go? 🤔
* manged by DEP
* says which revisions were last picked by dep
* Notice that the manifest said "0.8.0" but the version is "v0.8.1" RANGES!
* Same for pkg/errors, dep picked the highest version on the master branch
They are more what you'd call "guidelines"...
dep prefers ranges over specific versions
1.2.3 becomes >=1.2.3, <2.0.0
0.2.3 becomes >=0.2.3, <0.3.0
0.0.3 becomes >=0.0.3, <0.1.0
Use =0.8.1 to pin to a version
* why dep automatically uses ranges
* PSA - dep can't pull versions out of its butt, so start tagging your releases!
Vendor Directory
Owned by dep No files are safe from its tyranny!
Check it in for a smug sense of superiority
* says which revisions were last picked by dep
dep init
* default looks for existing glide/godep config and falls back picking the highest compatible version from the repo
* gopath optional - if you are cool like that, and your gopath isn't a steaming 💩
You are making a fresh start
dep init
Identifies your dependencies.
Checks if your dependencies use dep.
Picks the highest compatible version for each dependency.
You are already using another dependency manager
dep init
Imports your existing configuration.
Checks if your dependencies use dep.
Falls back to the simple case to fill in gaps.
We try to end up with you using the exact same revisions as you were with the other tool.
Your GOPATH isn't a steaming 💩
dep init -gopath
Uses the branch/version/revision found in GOPATH.
Checks if your dependencies use dep.
Falls back to the simple case to fill in gaps.
Great for when it's working on your computer.
Your dependencies are already vendored
dep init
Makes a backup of vendor and takes over.
Generates an initial set of configuration files.These do not match your original vendor !
Leaves it up to you to fix them by hand... Sorry.
dep ensure
Run on fresh clones if you don't check-in vendor
Run after modifying your manifest
dep status
PROJECT CONSTRAINT VERSION REVISION LATEST
github.com/Masterminds/semver branch 2.x branch 2.x 139cc09 c2e7f6c
github.com/Masterminds/vcs ^1.11.0 v1.11.1 3084677 3084677
github.com/armon/go-radix * branch master 4239b77 4239b77
See what you are using and check your lock for problems.
How do I add a dependency?
Add an import statement.
Run dep ensure.
We are working on make this work better for those using IDEs.
How do I update a dependency?
dep ensure -update -n
dep ensure -update
dep ensure -update github.com/carolynvs/loves-ponies
dep ensure -update github.com/carolynvs/loves-ponies@v2.0.1
Update everything, one thing using the manifest, one thing to a specific version/branch/revision
How do I remove a dependency?
Stop using it in your code.
Run dep ensure.
If it was in your manifest, you may remove it.
dep ensure tries to do the right thing in the face of oddball config.
If you have defined a constraint for something not used, dep ignores it
and it won't end up in the lock or vendor/.
How do I test uncommitted changes to a dependency?
Delete it from the vendor directory.
Avoid running dep ensure for a wee bit.
Make your changes to the project in your GOPATH.
Don't work on the code from within the vendor directory.
Alternatively, work on a fork and use the source property in your manifest.
The Floor is Lava
🤞 The config file format is stable.
🎉 dep init is ready for you to try out!
🚧 dep ensure has big changes fermenting in a PR.
Not all dep mgmt supported yet.
dep ensure is staying
Fun problems yet to be solved
Enterprise / Private Repositories
os, arch and build tags
Local repositories
Long-term support for other tools