dep was the tool I used. There are a few other solutions but this one was most popular when I last looked.
https://github.com/golang/dep
In Go 1.11 Rc1 releasedgolang
dep
Go2017–2023
golang / dep · Archived
dep
Go dependency management tool experiment (deprecated)
46Distinct people
48Mentions
0Explicit recommenders
12.7KGitHub stars
What to know before exploring
What it is
Go dependency management tool experiment (deprecated)
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- getstream/vg · linked in 3 of the same discussions
- golang/go · linked in 2 of the same discussions
- kardianos/govendor · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:03:49 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year48 dated mentions
Observed mentions: 2017-01-24 16:39:45 UTC to 2023-01-10 02:44:15 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 25 | 7 | 18 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 20 | 0 | 20 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Dep
dep is a dependency management tool for Go. It requires Go 1.9 or newer to compile.
NOTE: Dep was an official experiment to implement a package manager for Go.
As of 2020, Dep is deprecated and archived in favor of Go modules, which have
had official support since Go 1.11. For more details, see https://golang.org/ref/mod.
For guides and reference materials about dep, see the documentation.
Installation
You should use an officially released version. Release binaries are available on
the releases page.
On MacOS you can install or upgrade to the latest released version with Homebrew:
$ brew install dep
$ brew upgrade dep
On Debian platforms you can install or upgrade to the latest version with apt-get:
$ sudo apt-get install go-dep
On Windows, you can download a tarball from
go.equinox.io.
On other platforms you can use the install.sh script:
$ curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
It will install into your $GOPATH/bin directory by default or any other directory you specify using the INSTALL_DIRECTORY environment variable.
If your platform is not supported, you'll need to build it manually or let the team know and we'll consider adding your platform
to the release builds.
If you're interested in getting the source code, or hacking on dep, you can
install via go get:
go get -u github.com/golang/dep/cmd/dep
Read the full README on GitHubWhat Hacker News says
20 sourcesIndeed, as I said, Dep is okay when it works, until it doesn't. This [1], for example, is a blocking issue, and requires some manual editing of the lock file to get around. I've had other issues. The issues pale in comparison to the horribleness of Glide, but it's interesting just how these tools end up being so damn flaky.
[1] https://github.com/golang/dep/issues/1207
In Taking Go modules for a spin> My personal theory is that what made Russ Cox cave in was his discussions with Sam Boyer. Cox thought Boyer was going down the wrong path, and thought he had a better solution.
That's certainly my understanding of the situation. Matt Farina has a great commented history of dep and vgo [0] if you haven't already seen it. The comments are particularly enlightening.
Still, it's not clear to me what made the Go team get into the package management game at all. As you say, for years they were happy to leave that as a community problem. But something spurred them to declare that Dep was an "official experiment."
> Dep is okay when it works, but inherits pretty much all the warts of Glide, which Boyer also worked on.
Funny, I've had exactly the opposite experience. Glide caused us plenty of trouble at CockroachDB, but Dep has worked flawlessly
Read the rest
, if slowly. I've also found Sam to be exceptionally friendly and responsive to feedback [1] [2].
[0]: https://codeengineered.com/blog/2018/golang-godep-to-vgo/#co...
[1]: https://github.com/golang/dep/issues/1927
[2]: https://github.com/golang/dep/issues/460
Rust/Cargo had the luxury of being a greenfield project that could adopt semver from the beginning, whereas Go made the mistake of starting out, and then going years, without any official package management solution. As a result, Go has a swathe of applications and libraries that use specific workflows as well as a mélange of community-developed package management tools such as godep, Glide and dep. The semver standard, in particular, has been inconsistently adopted by the Go community.
In other words, any new Go tool either has to support/import existing code, or to wipe the slate clean and say that for a package to be importable it has to follow a new spec. dep decided on the former, and my impression is that this has had unfortunate consequences, because that inherits a lot of historical baggage.
We've been using dep for a while (havi
Read the rest
ng escaped the bugfest that is Glide, which used a very similar approach), and it's pretty evident that the solver is buggy and slow and also complicated enough that fixing issues like [1] can only be done by a select few that already understand the codebase. I'm not in a position to judge what the causes of all of these issues are, though I'd wager they're not entirely unrelated to the inherent complexity of SAT solving. The current dep issue tracker is full [2] of reports mentioning the solver, not to mention that dep currently has problems with known libraries such as the Kubernetes client [3] and Protobuf. (Google-related projects have historically used godep.) Again, possibly related to this specific implementation and not necessarily something that would apply to a hypothetical "Cargo for Go", but I don't know.
Any idea how Cargo compares to dep overall?
[1] https://github.com/golang/dep/issues/1306 — this one is a nightmare if you work anything related to Kubernetes.
[2] https://github.com/golang/dep/issues?q=is%3Aissue+is%3Aopen+...
[3] https://github.com/golang/dep/issues/1207
What do you mean by "no solid dependency management"? Do you mean out of the box? This used to be true, but with glide and dep (https://github.com/golang/dep) it seems to. It is not npm or bundler - but progressing.
In Go: The Good, the Bad and the UglyThe constant thrash caused by the lack of a standard package management tool—even a de facto standard. Just look at the various package managers that have come and gone over the years:
1. https://github.com/tools/godep
2. https://github.com/kardianos/govendor
3. https://github.com/robfig/glock
4. https://github.com/rogpeppe/govers
5. https://github.com/Masterminds/glide
6. https://github.com/golang/dep
I'm sure I'm forgetting a few. And just when it seemed the Go team might be ready to standardize around Dep (6), they threw this wrench in the works.
I'm of two minds about vgo. I think it has some interesting ideas, but Dep works today, is widely adopted, and has nearly all the features you'd expect from a modern package manager.
In A Proposal for Package Versioning in GoIs anyone else using golang dep[1] as their vendor/dependency tool?
I’ve used it and it works great (much better than glide, gb et al) but I don’t see it in the wild too often.
[1] https://github.com/golang/dep
In Go best practices, six years in (2016)dep will ignore the library's vendor directory entirely. You don't need to do any of that work yourself. dep will do it for you.
https://github.com/golang/dep
In Go and Versioning: Minimal Version SelectionThere's a bunch of external packages. One by the go team: https://github.com/golang/dep
In Go += Package VersioningWhile it's not perfect, if you use Dep and VG your vendoring issues are pretty much solved: https://github.com/getstream/vg https://github.com/golang/dep
In Why I Don't Like Golang (2016)I think this is on the roadmap but I'm not sure the priority. Check out this proposal https://gist.github.com/sdboyer/def9b138af448f39300cb078b0e9...
EDIT: Found the proposal on the dep roadmap: https://github.com/golang/dep/wiki/Roadmap
In Go 1.10 Release NotesTake a look at the dep[1] tool. It allows you to ship your project with all of its dependencies included. This means that only your source is needed to build your application/package.
The Gopkg.toml/Gopkg.lock files in dep are quite similar to Rust's Cargo.toml/Cargo.lock files. I think it's a good move as Rust has probably the best package management story out there.
Also, as the other comment mentioned, github.com is not "special" in any way. Any website with a git repo will work just as well. In fact, some key libraries are served from golang.org/x/<whatever>[2] not github.com.
[1]https://github.com/golang/dep
[2]https://github.com/golang/go/wiki/SubRepositories
In Go accepts patches from GitHub pull requests now> "You can override the location of a package with dep."
As far as I know, this is true [1], and can be done with the 'source' rule in Gopkg.toml. However, the guidance for dep says [1]:
"A source rule can specify an alternate location from which the name'd project should be retrieved. It is primarily useful for temporarily specifying a fork for a repository. source rules are generally brittle and should only be used when there is no other recourse. Using them to try to circumvent network reachability issues is typically an antipattern."
This doesn't sound like a glowing endorsement of this feature.
> "Indirection doesn't solve the problem it just moves it to the centralized repository."
Precisely; we're in agreement. A repository can then choose to institute sensible rules, if they so desire: Maven Central has what I would consider to be
Read the rest
sensible rules, while NPM prior to 'left-pad' did not. Without a repository, the community has no place to make this decision point, so everyone's left to fend for themselves.
> "Go designers recommend vendoring packages which solves the problem."
Can you point me to guidance from Go designers which substantiates your point? I have been searching for this and have been unable to find it.
[1] https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
Another reason to always vendor [1] your dependencies...
[1] - https://github.com/golang/dep
In GitHub shouldn't allow username reuseShowing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.