dep: officially deprecate the "dep" experiment

[daenney]

This is a request to officially deprecate the "dep" package manager for Go, and would resolve #35894.

Rationale

The Go ecosystem has moved towards Go Modules, introduced in Go 1.11 and considered stable and production ready since 1.14. Many projects have started migrating to Go Modules, or already completed that migration since Go 1.12 was released.

Despite the fact that the Go project and Go ecosystem have largely embraced modules, dep remains in use by people. Unfortunately most if not all dep maintainers have moved on from the project. The net result of this is though people do still submit issues to the issue tracker and the occasional PR, no help is offered or review is received. This is not a good experience for any member of the Go community.

Changes

I would like to propose the following:

• The PR from @ALTree on README: clarify current status of Go dependency management dep#2233 is merged, or language to that same effect is added to the README of dep
• Any outstanding issues and PRs are closed with a "this project is no longer maintained, so we are not able to answer your question or accept new changes", or something like this
• The dep repository is archived on GitHub, resulting in the repository becoming read-only. This still allows anyone to explore and learn from the code, even fork it and build a new community around it should they want to, without creating the illusion that this is still a maintained tool by the Go project

[rsc]

Thanks for filing this proposal. We have been leaving Dep status alone and letting the users decide when they move. I saw @ALTree's PR and was waiting to see if the Dep maintainers had any comments. Using the proposal process seems like a good way to decide what to do with that PR.

Here are some recent numbers I gathered, not specifically for this issue. I built a list of ~all the public GitHub projects with ≥ 1000 stars and also downloaded some basic metadata about the default branch of the repo. This lets us understand a little about the current state of popular projects, including popular Go projects.

Out of 23,531 projects, 1,033 have a .go file in the root directory. Of those 640/1,033 (62%) also have a go.mod file. There are another 237 which have a go.mod but no .go sources, presumably because their Go sources are in subdirectories. If we include those, we have 877/1,270 (69%). For comparison, 73/1,033 (7.1%) have dep's Gopkg.toml, and 19/1,033 (2%) have godep's Godeps directory. There is a small amount of overlap: 11 have both go.mod and Gopkg.toml, so Dep-only is 62/1,033 (6.0%).

Limiting to projects for which the HEAD commit happened in the past six months, 588/742 (80%) or 812/966 (84%) use modules. Dep is 40/742 (5.4%). Dep-only is 32/742 (4.3%).

Limiting to the past three months, 515/629 (82%) or 727/841 (86%) use modules. Dep is 37/629 (5.9%). Dep-only is 29/629 (4.6%); full list below in the toggle.

So it looks like there are still a few active Dep users, but most of the Go user base has migrated at this point. Like I said, we'll put this through the proposal process and get this into the minutes for this week. Thanks.

---

The 29 dep-only GitHub projects with ≥ 1000 stars and commits in 2020

project	branch	last commit
GetStream/vg	master	2020-01-16T14:39:29Z
GoBelieveIO/im_service	master	2020-01-02T11:53:05Z
GoogleContainerTools/container-diff	master	2020-02-13T15:34:58Z
Originate/git-town	master	2020-02-29T16:43:17Z
boyter/scc	master	2020-03-23T01:11:08Z
centrifugal/centrifugo	master	2020-03-12T16:06:21Z
cloud66-oss/habitus	master	2020-02-05T17:10:28Z
cloudflare/redoctober	master	2020-01-17T18:03:38Z
convox/rack	master	2020-02-27T16:44:09Z
docker/app	master	2020-01-07T16:27:28Z
esimov/triangle	master	2020-02-10T10:33:31Z
fortio/fortio	master	2020-03-11T22:31:16Z
gravitational/teleport	master	2020-03-21T00:57:05Z
gruntwork-io/terragrunt	master	2020-03-19T10:03:22Z
influxdata/kapacitor	master	2020-01-21T18:42:59Z
inlets/inlets	master	2020-03-10T14:42:51Z
juju/juju	develop	2020-03-23T13:14:32Z
loadimpact/k6	master	2020-03-23T12:15:06Z
minishift/minishift	master	2020-03-12T14:33:09Z
play-with-docker/play-with-docker	master	2020-02-26T02:37:46Z
requilence/integram	master	2020-01-14T09:00:29Z
rfjakob/gocryptfs	master	2020-02-29T20:52:59Z
ro31337/libretaxi	master	2020-02-27T22:55:33Z
shirou/gopsutil	master	2020-03-14T13:36:25Z
sosedoff/pgweb	master	2020-03-16T01:54:17Z
sourcegraph/go-langserver	master	2020-03-03T00:36:35Z
stripe/veneur	master	2020-02-10T22:18:51Z
twitchtv/twirp	master	2020-01-22T18:01:08Z
u-root/u-root	master	2020-03-21T00:56:35Z

[narqo]

@rsc could I point out, that, from personal experience, dependency management is generally more critical for (private) applications, than for (open source) libraries. I suspect, that by counting raw numbers of users it will make it look like 100 small and popular libraries, that "don't care what dependency management system they use", overweight 1 large application, that uses those libraries.

Clarifying the status of dep is very important for companies' so they can move towards to modules. Right now, because dep is part of golang's GitHub organisation and it isn't officially deprecated, it isn't clear for management and development if they must invest in changing what used to work or they can wait until dep will catch up.

[rsc]

Does anyone object to accepting this proposal?

[rsc]

Based on the (lack of) discussion above, this seems like a likely accept. I will also comment on golang/dep#2233.

[daenney]

I see golang/dep#2233 got merged, which is great. I'm wondering if we should add some stronger language though, stating that the project is no longer maintained and everyone is encouraged to migrate to modules?

[mvdan]

The top of the README also asks for funding, which is a bit weird for a deprecated experiment.

I think we should archive the github repository in the short term, to clarify that it's there for historical reasons, and won't see more development in the future as part of the Go project.