Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dep: officially deprecate the "dep" experiment #38158

Open
daenney opened this issue Mar 30, 2020 · 11 comments
Open

dep: officially deprecate the "dep" experiment #38158

daenney opened this issue Mar 30, 2020 · 11 comments

Comments

@daenney
Copy link

@daenney daenney commented Mar 30, 2020

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 golang/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
Copy link
Contributor

@rsc rsc commented Mar 31, 2020

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
@rsc rsc changed the title proposal: Officially deprecate the "dep" experiment proposal: officially deprecate the "dep" experiment Apr 1, 2020
@rsc rsc moved this from Incoming to Active in Proposals Apr 1, 2020
@rsc rsc changed the title proposal: officially deprecate the "dep" experiment proposal: dep: officially deprecate the "dep" experiment Apr 1, 2020
@narqo
Copy link
Contributor

@narqo narqo commented Apr 2, 2020

@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
Copy link
Contributor

@rsc rsc commented Apr 8, 2020

Does anyone object to accepting this proposal?

@rsc
Copy link
Contributor

@rsc rsc commented Apr 15, 2020

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

@rsc rsc moved this from Active to Likely Accept in Proposals Apr 15, 2020
@daenney
Copy link
Author

@daenney daenney commented Apr 16, 2020

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
Copy link
Member

@mvdan mvdan commented Apr 16, 2020

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.

@flibustenet
Copy link

@flibustenet flibustenet commented Apr 17, 2020

There is also https://golang.github.io/dep/ which doesn't mention modules at all.

@mvdan
Copy link
Member

@mvdan mvdan commented Apr 17, 2020

Good point, @flibustenet. It's the second result when one googles "go dep", so I think it should be fixed up too. The source seems to be under the same repo, at https://github.com/golang/dep/tree/master/website.

@daenney
Copy link
Author

@daenney daenney commented Apr 17, 2020

Alright, so follow-ups so far:

  • Add clearer deprecation warning to Dep README
  • Remove call for funding on dep
  • Close issues and PRs
  • Add deprecation warning and point to modules for golang.github.io/dep, or perhaps just redirect directly to https://blog.golang.org/using-go-modules
  • Archive dep
@rsc
Copy link
Contributor

@rsc rsc commented Apr 22, 2020

Because this is a significant issue, I'm going to leave this for an extra week of "likely accept" before moving it to accepted. I note that golang/dep#2233 has been merged, so what's being proposed here has become a smaller delta.

@rsc
Copy link
Contributor

@rsc rsc commented Apr 29, 2020

No change in consensus here, so accepting.

@rsc rsc moved this from Likely Accept to Accepted in Proposals Apr 29, 2020
@rsc rsc modified the milestones: Proposal, Backlog May 1, 2020
@rsc rsc changed the title proposal: dep: officially deprecate the "dep" experiment dep: officially deprecate the "dep" experiment May 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Accepted
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.