x/tools/go/vcs: deprecate, isolate, tag, and delete package #57051
Comments
|
(CC @golang/tools-team) Other related proposals / feature-requests include:
And if we adopt this proposal, we would presumably close out as obsolete: |
jeffwidman
added a commit
to dependabot/dependabot-core
that referenced
this issue
Apr 10, 2023
Over time, we've managed to thin out our custom `go` helper in favor of native package manager tooling via `go list`, `go get`, and `go mod`. The final remaining usage was for translating package import URLs into the actual repository URL for fetching metadata. The original impetus for the `github.com/Masterminds/vcs` library was that it was a copy/paste of some code in core `go`: [Further context](#4448 (comment)): > I think the code is trying to map a Go import path back to a repository so we can e.g. link to the repo in the Dependabot PR, find the CHANGELOG, link to the diff between versions, etc, etc. > It’s not totally trivial with Go because: > 1. they’ve got that whole vanity URL thing going on, where you have to pass `go-get=1` in to make it act like a fancy redirect to a repo > 2. a Go import path doesn’t necessarily actually match a repo URL. For instance, I might be able to import https://github.com/go-kit/kit/tracing, but that’s not a valid URL on GitHub. The repo is [github.com/go-kit/kit](http://github.com/go-kit/kit), and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some [logic](https://github.com/golang/go/blob/95c125a44ad1a0c3e441c3214160cd7b4483e79c/src/cmd/go/internal/vcs/vcs.go#L1437) to handle that for a series of SCMs, and the Masterminds/vcs package does a [similar thing](https://github.com/Masterminds/vcs/blob/master/vcs_remote_lookup.go) too. > > Ideally, we’d just use whatever golang/go does, but IIRC that wasn’t importable so the next best thing was the Masterminds/vcs implementation. The Ruby code you linked to predates our usage of that Go library, and I’d guess is just a really incomplete Ruby implementation of the same thing. > Perhaps these days a) there’s a good Ruby implementation, or b) we think the VCS list is stable enough we’d be happy to translate it to Ruby, or c) we could somehow codegen the Ruby from the canonical Go implementation? Or we just stick with that one-off Go helper? However, I discovered after doing some digging in #6938 that there _is_ both an upstream copy (golang/go#18387 (comment)), which may potentially get deprecated (golang/go#57051). Furthermore, there _is_ actually a `go list` command that provides enough of what we need: * golang/go#44742 ``` $ go list -m -f '{{.Origin}}' golang.org/x/tools@latest {git https://go.googlesource.com/tools refs/tags/v0.3.0 502c634771c4ba335286d55fc24eeded1704f592 } ``` While this doesn't fully resolve the upstream issue: * golang/go#18387 For our purposes it provides enough of what we need since we already have the module path extracted from `go.mod` (golang/go#18387 (comment)). Performing this switch allows us to completely delete the native go helper altogether. I debated leaving the framework in place in case we later wish to extend it for other features, but decided for now to rip it out as it's easy enough to add later. And in general we're trying to move toward leveraging native package manager tooling whenever possible. So if we later needed an additional feature, we're probably start with a discussion with the `go` team to see if they'd build it into the `go` cmd tooling.
jeffwidman
added a commit
to dependabot/dependabot-core
that referenced
this issue
Apr 10, 2023
Over time, we've managed to thin out our custom `go` helper in favor of native package manager tooling via `go list`, `go get`, and `go mod`. The final remaining usage was for translating package import URLs into the actual repository URL for fetching metadata. The original impetus for the `github.com/Masterminds/vcs` library was that it was a copy/paste of some code in core `go`: [Further context](#4448 (comment)): > I think the code is trying to map a Go import path back to a repository so we can e.g. link to the repo in the Dependabot PR, find the CHANGELOG, link to the diff between versions, etc, etc. > It’s not totally trivial with Go because: > 1. they’ve got that whole vanity URL thing going on, where you have to pass `go-get=1` in to make it act like a fancy redirect to a repo > 2. a Go import path doesn’t necessarily actually match a repo URL. For instance, I might be able to import https://github.com/go-kit/kit/tracing, but that’s not a valid URL on GitHub. The repo is [github.com/go-kit/kit](http://github.com/go-kit/kit), and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some [logic](https://github.com/golang/go/blob/95c125a44ad1a0c3e441c3214160cd7b4483e79c/src/cmd/go/internal/vcs/vcs.go#L1437) to handle that for a series of SCMs, and the Masterminds/vcs package does a [similar thing](https://github.com/Masterminds/vcs/blob/master/vcs_remote_lookup.go) too. > > Ideally, we’d just use whatever golang/go does, but IIRC that wasn’t importable so the next best thing was the Masterminds/vcs implementation. The Ruby code you linked to predates our usage of that Go library, and I’d guess is just a really incomplete Ruby implementation of the same thing. > Perhaps these days a) there’s a good Ruby implementation, or b) we think the VCS list is stable enough we’d be happy to translate it to Ruby, or c) we could somehow codegen the Ruby from the canonical Go implementation? Or we just stick with that one-off Go helper? However, I discovered after doing some digging in #6938 that there _is both_ an upstream copy (golang/go#18387 (comment), which may potentially get deprecated golang/go#57051 and an actual `go list` command that provides enough of what we need: * golang/go#44742 ``` $ go list -m -f '{{.Origin}}' golang.org/x/tools@latest {git https://go.googlesource.com/tools refs/tags/v0.3.0 502c634771c4ba335286d55fc24eeded1704f592 } ``` While this doesn't fully resolve the upstream issue: * golang/go#18387 For our purposes it provides enough of what we need since we already have the module path extracted from `go.mod` (golang/go#18387 (comment)). Performing this switch allows us to completely delete the native go helper altogether. I debated leaving the framework in place in case we later wish to extend it for other features, but decided for now to rip it out as it's easy enough to add later. And in general we're trying to move toward leveraging native package manager tooling whenever possible. So if we later needed an additional feature, we're probably start with a discussion with the `go` team to see if they'd build it into the `go` cmd tooling.
jeffwidman
added a commit
to dependabot/dependabot-core
that referenced
this issue
Apr 10, 2023
Over time, we've managed to thin out our custom `go` helper in favor of native package manager tooling via `go list`, `go get`, and `go mod`. The final remaining usage was for translating package import URLs into the actual repository URL for fetching metadata. The original impetus for the `github.com/Masterminds/vcs` library was that it was a copy/paste of some code in core `go`: [Further context](#4448 (comment)): > I think the code is trying to map a Go import path back to a repository so we can e.g. link to the repo in the Dependabot PR, find the CHANGELOG, link to the diff between versions, etc, etc. > It’s not totally trivial with Go because: > 1. they’ve got that whole vanity URL thing going on, where you have to pass `go-get=1` in to make it act like a fancy redirect to a repo > 2. a Go import path doesn’t necessarily actually match a repo URL. For instance, I might be able to import https://github.com/go-kit/kit/tracing, but that’s not a valid URL on GitHub. The repo is [github.com/go-kit/kit](http://github.com/go-kit/kit), and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some [logic](https://github.com/golang/go/blob/95c125a44ad1a0c3e441c3214160cd7b4483e79c/src/cmd/go/internal/vcs/vcs.go#L1437) to handle that for a series of SCMs, and the Masterminds/vcs package does a [similar thing](https://github.com/Masterminds/vcs/blob/master/vcs_remote_lookup.go) too. > > Ideally, we’d just use whatever golang/go does, but IIRC that wasn’t importable so the next best thing was the Masterminds/vcs implementation. The Ruby code you linked to predates our usage of that Go library, and I’d guess is just a really incomplete Ruby implementation of the same thing. > Perhaps these days a) there’s a good Ruby implementation, or b) we think the VCS list is stable enough we’d be happy to translate it to Ruby, or c) we could somehow codegen the Ruby from the canonical Go implementation? Or we just stick with that one-off Go helper? However, I discovered after doing some digging in #6938 that there _is both_ an upstream copy (golang/go#18387 (comment), which may potentially get deprecated golang/go#57051) and an actual `go list` command that provides enough of what we need: * golang/go#44742 ``` $ go list -m -f '{{.Origin}}' golang.org/x/tools@latest {git https://go.googlesource.com/tools refs/tags/v0.3.0 502c634771c4ba335286d55fc24eeded1704f592 } ``` While this doesn't fully resolve the upstream issue: * golang/go#18387 For our purposes it provides enough of what we need since we already have the module path extracted from `go.mod` (golang/go#18387 (comment)). Performing this switch allows us to completely delete the native go helper altogether. I debated leaving the framework in place in case we later wish to extend it for other features, but decided for now to rip it out as it's easy enough to add later. And in general we're trying to move toward leveraging native package manager tooling whenever possible. So if we later needed an additional feature, we're probably start with a discussion with the `go` team to see if they'd build it into the `go` cmd tooling.
jeffwidman
added a commit
to dependabot/dependabot-core
that referenced
this issue
Apr 10, 2023
Over time, we've managed to thin out our custom `go` helper in favor of native package manager tooling via `go list`, `go get`, and `go mod`. The final remaining usage was for translating package import URLs into the actual repository URL for fetching metadata. The original impetus for the `github.com/Masterminds/vcs` library was that it was a copy/paste of some code in core `go`: [Further context](#4448 (comment)): > I think the code is trying to map a Go import path back to a repository so we can e.g. link to the repo in the Dependabot PR, find the CHANGELOG, link to the diff between versions, etc, etc. > It’s not totally trivial with Go because: > 1. they’ve got that whole vanity URL thing going on, where you have to pass `go-get=1` in to make it act like a fancy redirect to a repo > 2. a Go import path doesn’t necessarily actually match a repo URL. For instance, I might be able to import https://github.com/go-kit/kit/tracing, but that’s not a valid URL on GitHub. The repo is [github.com/go-kit/kit](http://github.com/go-kit/kit), and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some [logic](https://github.com/golang/go/blob/95c125a44ad1a0c3e441c3214160cd7b4483e79c/src/cmd/go/internal/vcs/vcs.go#L1437) to handle that for a series of SCMs, and the Masterminds/vcs package does a [similar thing](https://github.com/Masterminds/vcs/blob/master/vcs_remote_lookup.go) too. > > Ideally, we’d just use whatever golang/go does, but IIRC that wasn’t importable so the next best thing was the Masterminds/vcs implementation. The Ruby code you linked to predates our usage of that Go library, and I’d guess is just a really incomplete Ruby implementation of the same thing. > Perhaps these days a) there’s a good Ruby implementation, or b) we think the VCS list is stable enough we’d be happy to translate it to Ruby, or c) we could somehow codegen the Ruby from the canonical Go implementation? Or we just stick with that one-off Go helper? However, I discovered after doing some digging in #6938 that there _is both_ an upstream copy (golang/go#18387 (comment), which may potentially get deprecated golang/go#57051) and an actual `go list` command that provides enough of what we need: * golang/go#44742 ``` $ go list -m -f '{{.Origin}}' golang.org/x/tools@latest {git https://go.googlesource.com/tools refs/tags/v0.3.0 502c634771c4ba335286d55fc24eeded1704f592 } ``` While this doesn't fully resolve the upstream issue: * golang/go#18387 For our purposes it provides enough of what we need since we already have the module path extracted from `go.mod` (golang/go#18387 (comment)). Performing this switch allows us to completely delete the native go helper altogether. I debated leaving the framework in place in case we later wish to extend it for other features, but decided for now to rip it out as it's easy enough to add back later. And in general we're trying to move toward leveraging native package manager tooling whenever possible. So if we later needed an additional feature, we're probably start with a discussion with the `go` team to see if they'd build it into the `go` cmd tooling.
jeffwidman
added a commit
to dependabot/dependabot-core
that referenced
this issue
Apr 10, 2023
Over time, we've managed to thin out our custom `go` helper in favor of native package manager tooling via `go list`, `go get`, and `go mod`. The final remaining usage was for translating package import URLs into the actual repository URL for fetching metadata. The original impetus for the `github.com/Masterminds/vcs` library was that it was a copy/paste of some code in core `go`: [Further context](#4448 (comment)): > I think the code is trying to map a Go import path back to a repository so we can e.g. link to the repo in the Dependabot PR, find the CHANGELOG, link to the diff between versions, etc, etc. > It’s not totally trivial with Go because: > 1. they’ve got that whole vanity URL thing going on, where you have to pass `go-get=1` in to make it act like a fancy redirect to a repo > 2. a Go import path doesn’t necessarily actually match a repo URL. For instance, I might be able to import https://github.com/go-kit/kit/tracing, but that’s not a valid URL on GitHub. The repo is [github.com/go-kit/kit](http://github.com/go-kit/kit), and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some [logic](https://github.com/golang/go/blob/95c125a44ad1a0c3e441c3214160cd7b4483e79c/src/cmd/go/internal/vcs/vcs.go#L1437) to handle that for a series of SCMs, and the Masterminds/vcs package does a [similar thing](https://github.com/Masterminds/vcs/blob/master/vcs_remote_lookup.go) too. > > Ideally, we’d just use whatever golang/go does, but IIRC that wasn’t importable so the next best thing was the Masterminds/vcs implementation. The Ruby code you linked to predates our usage of that Go library, and I’d guess is just a really incomplete Ruby implementation of the same thing. > Perhaps these days a) there’s a good Ruby implementation, or b) we think the VCS list is stable enough we’d be happy to translate it to Ruby, or c) we could somehow codegen the Ruby from the canonical Go implementation? Or we just stick with that one-off Go helper? However, I discovered after doing some digging in #6938 that there _is both_ an upstream copy (golang/go#18387 (comment), which may potentially get deprecated golang/go#57051) and an actual `go list` command that provides enough of what we need: * golang/go#44742 ``` $ go list -m -f '{{.Origin}}' golang.org/x/tools@latest {git https://go.googlesource.com/tools refs/tags/v0.3.0 502c634771c4ba335286d55fc24eeded1704f592 } ``` While this doesn't fully resolve the upstream issue: * golang/go#18387 For our purposes it provides enough of what we need since we already have the module path extracted from `go.mod` (golang/go#18387 (comment)). Performing this switch allows us to completely delete the native go helper altogether. I debated leaving the framework in place in case we later wish to extend it for other features, but decided for now to rip it out as it's easy enough to add back later. And in general we're trying to move toward leveraging native package manager tooling whenever possible. So if we later needed an additional feature, we're probably start with a discussion with the `go` team to see if they'd build it into the `go` cmd tooling.
jeffwidman
added a commit
to dependabot/dependabot-core
that referenced
this issue
Apr 10, 2023
Over time, we've managed to thin out our custom `go` helper in favor of native package manager tooling via `go list`, `go get`, and `go mod`. The final remaining usage was for translating package import URLs into the actual repository URL for fetching metadata. The original impetus for the `github.com/Masterminds/vcs` library was that it was a copy/paste of some code in core `go`: [Further context](#4448 (comment)): > I think the code is trying to map a Go import path back to a repository so we can e.g. link to the repo in the Dependabot PR, find the CHANGELOG, link to the diff between versions, etc, etc. > It’s not totally trivial with Go because: > 1. they’ve got that whole vanity URL thing going on, where you have to pass `go-get=1` in to make it act like a fancy redirect to a repo > 2. a Go import path doesn’t necessarily actually match a repo URL. For instance, I might be able to import https://github.com/go-kit/kit/tracing, but that’s not a valid URL on GitHub. The repo is [github.com/go-kit/kit](http://github.com/go-kit/kit), and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some [logic](https://github.com/golang/go/blob/95c125a44ad1a0c3e441c3214160cd7b4483e79c/src/cmd/go/internal/vcs/vcs.go#L1437) to handle that for a series of SCMs, and the Masterminds/vcs package does a [similar thing](https://github.com/Masterminds/vcs/blob/master/vcs_remote_lookup.go) too. > > Ideally, we’d just use whatever golang/go does, but IIRC that wasn’t importable so the next best thing was the Masterminds/vcs implementation. The Ruby code you linked to predates our usage of that Go library, and I’d guess is just a really incomplete Ruby implementation of the same thing. > Perhaps these days a) there’s a good Ruby implementation, or b) we think the VCS list is stable enough we’d be happy to translate it to Ruby, or c) we could somehow codegen the Ruby from the canonical Go implementation? Or we just stick with that one-off Go helper? However, I discovered after doing some digging in #6938 that there _is both_ an upstream copy (golang/go#18387 (comment), which may potentially get deprecated golang/go#57051) and an actual `go list` command that provides enough of what we need: * golang/go#44742 ``` $ go list -m -f '{{.Origin}}' golang.org/x/tools@latest {git https://go.googlesource.com/tools refs/tags/v0.3.0 502c634771c4ba335286d55fc24eeded1704f592 } ``` While this doesn't fully resolve the upstream issue: * golang/go#18387 For our purposes it provides enough of what we need since we already have the module path extracted from `go.mod` (golang/go#18387 (comment)). Performing this switch allows us to completely delete the native go helper altogether. I debated leaving the framework in place in case we later wish to extend it for other features, but decided for now to rip it out as it's easy enough to add back later. And in general we're trying to move toward leveraging native package manager tooling whenever possible. So if we later needed an additional feature, we're probably start with a discussion with the `go` team to see if they'd build it into the `go` cmd tooling.
jeffwidman
added a commit
to dependabot/dependabot-core
that referenced
this issue
Apr 10, 2023
Over time, we've managed to thin out our custom `go` helper in favor of native package manager tooling via `go list`, `go get`, and `go mod`. The final remaining usage was for translating package import URLs into the actual repository URL for fetching metadata. The original impetus for the `github.com/Masterminds/vcs` library was that it was a copy/paste of some code in core `go`: [Further context](#4448 (comment)): > I think the code is trying to map a Go import path back to a repository so we can e.g. link to the repo in the Dependabot PR, find the CHANGELOG, link to the diff between versions, etc, etc. > It’s not totally trivial with Go because: > 1. they’ve got that whole vanity URL thing going on, where you have to pass `go-get=1` in to make it act like a fancy redirect to a repo > 2. a Go import path doesn’t necessarily actually match a repo URL. For instance, I might be able to import https://github.com/go-kit/kit/tracing, but that’s not a valid URL on GitHub. The repo is [github.com/go-kit/kit](http://github.com/go-kit/kit), and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some [logic](https://github.com/golang/go/blob/95c125a44ad1a0c3e441c3214160cd7b4483e79c/src/cmd/go/internal/vcs/vcs.go#L1437) to handle that for a series of SCMs, and the Masterminds/vcs package does a [similar thing](https://github.com/Masterminds/vcs/blob/master/vcs_remote_lookup.go) too. > > Ideally, we’d just use whatever golang/go does, but IIRC that wasn’t importable so the next best thing was the Masterminds/vcs implementation. The Ruby code you linked to predates our usage of that Go library, and I’d guess is just a really incomplete Ruby implementation of the same thing. > Perhaps these days a) there’s a good Ruby implementation, or b) we think the VCS list is stable enough we’d be happy to translate it to Ruby, or c) we could somehow codegen the Ruby from the canonical Go implementation? Or we just stick with that one-off Go helper? However, I discovered after doing some digging in #6938 that there _is both_ an upstream copy (golang/go#18387 (comment), which may potentially get deprecated golang/go#57051) and an actual `go list` command that provides enough of what we need: * golang/go#44742 ``` $ go list -m -f '{{.Origin}}' golang.org/x/tools@latest {git https://go.googlesource.com/tools refs/tags/v0.3.0 502c634771c4ba335286d55fc24eeded1704f592 } ``` While this doesn't fully resolve the upstream issue: * golang/go#18387 For our purposes it provides enough of what we need since we already have the module path extracted from `go.mod` (golang/go#18387 (comment)). Performing this switch allows us to completely delete the native go helper altogether. I debated leaving the framework in place in case we later wish to extend it for other features, but decided for now to rip it out as it's easy enough to add back later. And in general we're trying to move toward leveraging native package manager tooling whenever possible. So if we later needed an additional feature, we're probably start with a discussion with the `go` team to see if they'd build it into the `go` cmd tooling.
|
Happy to tag and delete. |
|
Ok, expanding scope. I'll be happy to do this after proposal acceptance. |
dmitshur
changed the title
|
This proposal has been added to the active column of the proposals project |
|
Based on the discussion above, this proposal seems like a likely accept. |
|
No change in consensus, so accepted. 🎉 |
rsc
changed the title
|
Change https://go.dev/cl/505955 mentions this issue: |
|
Change https://go.dev/cl/159818 mentions this issue: |
|
Change https://go.dev/cl/505956 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Jun 26, 2023
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: 1. 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. 2. 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. In 2019, when this CL was mailed, deprecating seemed as the best option. In 2023, when this CL was merged, deprecating seemed as the best option. Fixes golang/go#11490. For golang/go#57051. Change-Id: Id32d2bec5706c4e87126b825de5215fa5d1ba8ac Reviewed-on: https://go-review.googlesource.com/c/tools/+/159818 gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Jun 26, 2023
The previous change marked the vcs package as deprecated. This change isolates it into a nested module where it will be tagged as v0.1.0-deprecated, its last version. The next change deletes the nested module from the tools repo. For golang/go#57051. Change-Id: I0b7df60dbe87c1d97f150e5f8ca10e9d281a9364 Reviewed-on: https://go-review.googlesource.com/c/tools/+/505955 gopls-CI: kokoro <noreply+kokoro@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
This was referenced Jun 26, 2023
sergiusens
added a commit
to canonical/snapcraft
that referenced
this issue
Jun 30, 2023
godeps can not longer build due to golang/go#57051 Instead of removing the godeps feature, disable the tests in case the upstream fixes the problem.
4 tasks
sergiusens
added a commit
to canonical/snapcraft
that referenced
this issue
Jun 30, 2023
godeps can not longer build due to golang/go#57051 Instead of removing the godeps feature, disable the tests in case the upstream fixes the problem.
grouville
pushed a commit
to grouville/go-vcs
that referenced
this issue
May 7, 2024
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: 1. 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. 2. 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. In 2019, when this CL was mailed, deprecating seemed as the best option. In 2023, when this CL was merged, deprecating seemed as the best option. Fixes golang/go#11490. For golang/go#57051. Change-Id: Id32d2bec5706c4e87126b825de5215fa5d1ba8ac Reviewed-on: https://go-review.googlesource.com/c/tools/+/159818 gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
grouville
pushed a commit
to grouville/go-vcs
that referenced
this issue
May 7, 2024
The previous change marked the vcs package as deprecated. This change isolates it into a nested module where it will be tagged as v0.1.0-deprecated, its last version. The next change deletes the nested module from the tools repo. For golang/go#57051. Change-Id: I0b7df60dbe87c1d97f150e5f8ca10e9d281a9364 Reviewed-on: https://go-review.googlesource.com/c/tools/+/505955 gopls-CI: kokoro <noreply+kokoro@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The documentation for golang.org/x/tools/go/vcs says:
I propose we deprecate the package. Motivation, copied from the commit message of CL 159818:
It seems that still applies today, and to a greater degree. Modern
go listhas enhancements like the newModule.Originfield that can help with module path → VCS resolution (#44742):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.
The text was updated successfully, but these errors were encountered: