Dep is a prototype dependency management tool. It requires Go 1.7 or newer to compile.
dep
is NOT an official tool. Yet. Check out the Roadmap!
dep
is safe for production use. That means two things:
- Any valid metadata file (
Gopkg.toml
andGopkg.lock
) will be readable and considered valid by any future version ofdep
. - Generally speaking, it has comparable or fewer bugs than other tools out there.
That said, keep in mind the following:
dep
is still changing rapidly. If you need stability (e.g. for CI), it's best to rely on a released version, not tip.- Some changes are pending to the CLI interface. Scripting on dep before they land is unwise.
dep
's exported API interface will continue to change in unpredictable, backwards-incompatible ways until we tag a v1.0.0 release.
- The Saga of Go Dependency Management
- Official Google Docs
- Frequently Asked Questions
Get the tool via
$ go get -u github.com/golang/dep/cmd/dep
To start managing dependencies using dep, run the following from your project root directory:
$ dep init
This does the following:
- Look for existing dependency management files to convert
- Check if your dependencies use dep
- Identify your dependencies
- Back up your existing
vendor/
directory (if you have one) to_vendor-TIMESTAMP/
- Pick the highest compatible version for each dependency
- Generate
Gopkg.toml
("manifest") andGopkg.lock
files - Install the dependencies in
vendor/
There is one main subcommand you will use: dep ensure
. ensure
first makes
sure Gopkg.lock
is consistent with your import
s and Gopkg.toml
. If any
changes are detected, it then populates vendor/
with exactly what's described
in Gopkg.lock
.
dep ensure
is safe to run early and often. See the help text for more detailed
usage instructions.
$ dep help ensure
(if your vendor/
directory isn't checked in with your code)
$ dep ensure
If a dependency already exists in your vendor/
folder, dep will ensure it
matches the constraints from the manifest. If the dependency is missing from
vendor/
, the latest version allowed by your manifest will be installed.
-
import
the package in your*.go
source code file(s). -
Run the following command to update your
Gopkg.lock
and populatevendor/
with the new dependency.$ dep ensure
If you want to:
- Change the allowed
version
/branch
/revision
- Switch to using a fork
for one or more dependencies, do the following:
-
Modify your
Gopkg.toml
. -
Run
$ dep ensure
$ 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
(to the latest version allowed by the manifest)
$ dep ensure -update
-
Remove the
import
s and all usage from your code. -
Run
$ dep ensure
-
Remove from
Gopkg.toml
, if it was in there.
Making changes in your vendor/
directory directly is not recommended, as dep
will overwrite any changes. Instead:
-
Delete the dependency from the
vendor/
directory.rm -rf vendor/<dependency>
-
Add that dependency to your
GOPATH
, if it isn't already.$ go get <dependency>
-
Modify the dependency in
$GOPATH/src/<dependency>
. -
Test, build, etc.
Don't run dep ensure
until you're done. dep ensure
will reinstall the
dependency into vendor/
based on your manifest, as if you were installing from
scratch.
This solution works for short-term use, but for something long-term, take a look at virtualgo.
To test out code that has been pushed as a new version, or to a branch or fork, see changing dependencies.
Feedback is greatly appreciated. At this stage, the maintainers are most interested in feedback centered on the user experience (UX) of the tool. Do you have workflows that the tool supports well, or doesn't support at all? Do any of the commands have surprising effects, output, or results? Please check the existing issues and FAQ to see if your feedback has already been reported. If not, please file an issue, describing what you did or wanted to do, what you expected to happen, and what actually happened.
Contributions are greatly appreciated. The maintainers actively manage the issues list, and try to highlight issues suitable for newcomers. The project follows the typical GitHub pull request model. See CONTRIBUTING.md for more details. Before starting any work, please either comment on an existing issue, or file a new one.