HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
golang
dep
Go2017–2023
golang / dep · Archived

dep

Go dependency management tool experiment (deprecated)

46Distinct people
48Mentions
0Explicit recommenders
12.7KGitHub stars
REPOSITORY AT A GLANCE

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

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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.

05101520252017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 25 mentions; 7 submissions, 18 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 20 mentions; 0 submissions, 20 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC25718
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC20020
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202

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 GitHub

What Hacker News says

48 sources
Oh excellent, then better (and more portable!) tools are available: http://pants.build https://ninja-build.org https://buck.build and, if you hate yourself: https://bazel.build > What exactly are you talking about? Are you upset that make isn't a cross-platform package management system? Ok, so you were serious with your claims of portability, that is concerning. The majority of times I've seen Make used it's primarily been as a task runner. For example: TAG=some-service SVC=website.com/$(TAG) BUILDER=golang:1.19-alpine export REVISION_ID?=unknown export BUILD_DATE?=unknown RUN=docker run --rm \ -v $(CURDIR):/opt/go/src/$(SVC) \ -w /opt/go/src/$(SVC) \ -e GO111MODULE=on build: ifeq ($(OS),Windows_NT) # Workaround on Windows for https://github.com/golang/dep/issues/1407 $(RUN) $(BU
Read the rest
ILDER) rm -rf vendor vendor.orig $(RUN) $(BUILDER) rm -rf vendor vendor.orig endif $(RUN) -e CGO_ENABLED=0 -e GOOS=linux $(BUILDER) \ go build -o service -ldflags "-s -X main.revisionID=$(REVISION_ID) -X main.buildDate=$(BUILD_DATE)" \ ./cmd/some-service/... # $(RUN) $(BUILDER) rhash --sha256 service -o service.sha256 docker build --tag="$(TAG):$(REVISION_ID)" --tag="$(TAG):latest" . run: docker-compose up serve: go run ./cmd/some-service/... dev: ulimit -n 1000 #increase the file watch limit, might required on MacOS reflex -s -r '\.go$$' make serve ^ the only thing this is "using" of Make is the name "Make" and it's so much worse to actually debug than a bash script, it's even got workarounds for various platforms inside of it.
In Just: A Command Runner
> when it appeared there was a clear winner Dep was very slow, tried to be very clever often resulting in it "cleverly" doing the wrong thing, and was generally a pain to deal with. At $dayjob we migrated to dep and then we had serious discussions if we should move back to glide (we didn't, as vgo was on the horizon by then). There were some plans to fix some of this IIRC, but they never really went beyond "plans". It's always difficult if people spend a lot of time on a particular solution and then it turns out that's actually not what's desired, or if someone else thinks of an even better solution. All option suck here: chucking out people's work sucks (especially in open source volunteer-effort context), but accepting a bad solution "because people spent time on it" and then being stuck with that for years or decades to come sucks even
Read the rest
more. The communication could certainly have been better; a sort of "community committee" was given a repo on github.com/golang/dep and told "good luck". In hindsight the Go team should have watched development more closely and provided feedback sooner so that the direction could be adjusted. Actually, the entire setup probably wasn't a good idea in hindsight.
In Sourcehut will blacklist the Go module mirror
It would seem this is correct. From the docs: https://github.com/golang/dep/blob/master/docs/FAQ.md#why-is... There are two things that really slow dep down. One is unavoidable; for the other, we have a plan. The unavoidable part is the initial clone. ... Fortunately, this is just an initial clone - pay it once, and you're done. The other part is the work of retrieving information about dependencies. There are three parts to this: * Getting an up-to-date list of versions from the upstream source * Reading the Gopkg.toml for a particular version out of the local cache * Parsing the tree of packages for import statements at a particular version The first requires one or more network calls; the second two usually mean something like a git checkout, and the third is a filesystem walk, plus loading and parsing .go files. All of these are expen
Read the rest
sive operations. ---------------- For context, in comparison, Cargo has the same #1 problem. But for #2, the information on all dependencies is stored in the index itself; this means that Cargo can figure out what dependencies you need without any network calls at all, let alone downloading, git checkout, and filesystem walk. I do not know how go mod compares, off the top of my head.
In The Principles of Versioning in Go
> 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
In Taking Go modules for a spin
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
In The vgo proposal is accepted. Now what?
The 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 Go

Showing the 15 most recent of 48 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.