x/tools/go/vcs: deprecate, isolate, tag, and delete package
dmitshur opened this issue · 9 comments
The documentation for golang.org/x/tools/go/vcs says:
Package vcs exposes functions for resolving import paths and using version control systems, which can be used to implement behavior similar to the standard "go get" command.
This package is a copy of internal code in package cmd/go/internal/get, modified to make the identifiers exported. It's provided here for developers who want to write tools with similar semantics. It needs to be manually kept in sync with upstream when changes are made to cmd/go/internal/get; see https://golang.org/issue/11490.
I propose we deprecate the package. Motivation, copied from the commit message of CL 159818:
This package has diverged significantly from actual cmd/go import path
resolution behavior. The recommended course of action is for people to
start using the go command itself, where this logic is guaranteed to be
up to date. cmd/go also has support for modules, while this package does
not.I've considered two alternatives to deprecating this package:
Not deprecate it, keep it as is. This is not a good option because
the package deviates from cmd/go import path resolution behavior and
doesn't have all security fixes backported to it. Keeping it in this
state without deprecating it can be misleading, since people may think
this package implements the stated goal of matching cmd/go behavior and
is well supported, which is not the current reality.Not deprecate it, try to make it up to date with cmd/go import path
resolution logic. This is not a good option because VCSs are no longer
guaranteed to exist for packages located inside modules. To expose the
import path to module resolution logic, the API of this package would
need to be significantly modified. At this time, my understanding is
such work is not in scope and people are encouraged to use the existing
go command instead.At this time, deprecating seems like the best option.
It seems that still applies today, and to a greater degree. Modern go list has enhancements like the new Module.Origin field that can help with module path → VCS resolution (#44742):
$ go list -m -f '{{.Origin}}' golang.org/x/tools@latest
{git https://go.googlesource.com/tools refs/tags/v0.3.0 502c634771c4ba335286d55fc24eeded1704f592 }
For anyone wishing to do something custom beyond what the go command offers, I believe they'd be much better off maintaining a copy of internal cmd/go code themselves or waiting on #18387, rather than using this package in the state it's been the last few years. Adding the deprecation notice is meant to help raise visibility on that, especially for people who are just discovering this package now.
(If the discussion weighs heavily in favor and wants to also isolate, tag, and delete package, increasing the scope would be fine with me.)
CC @bcmills.
Happy to tag and delete.
Ok, expanding scope. I'll be happy to do this after proposal acceptance.
This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group
Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group
No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group
Change https://go.dev/cl/505955 mentions this issue: go/vcs: isolate into a nested module
Change https://go.dev/cl/159818 mentions this issue: go/vcs: deprecate package in favor of go list -json
Change https://go.dev/cl/505956 mentions this issue: go/vcs: delete