This ensures that the `.info` files for all modules, which
get created by the Go command line tools under '$GOPATH/pkg/mod',
contain the VCS info. When using a Go proxy this is not guaranteed and
depends on the actual proxy instance, see [1]. This comes at the price
of increased execution time.

As the users environment may likely be configured to use a GOPROXY,
which is the default, use an empty directory to not mix-up newly cached
files with already existing ones which might have been created using a
Go proxy and therefore may lack the VCS info.

This prepares for using the Go tooling to determine the VCS info instead
of using ORT's partial reimplementation of that.

[1]: golang/go#44742 (comment)
[2]: golang/go#18387

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

Previously, ORT's GoMod integration had a rudimentary
(re-)implementation of the Go toolings' logic for resolving the VCS infos
for the dependencies, covering only the more common use cases. For
example, the implementation is VCS host specific and cannot handle mono
repository setup at all, without an ugly workaround in the downloader,
see [1]. Furthermore, I expect many not yet known issues in the more
uncommon use cases.

Avoid all these issue by just relying on the VCS info resolution of the
Go tooling.

Note that as of Go 1.19, the `.info` files under '$GOPATH/pkg/mod' are
guaranteed to contain the VCS info of the modules in case no Go proxy
is used [2]. For now that information is only accessible by parsing the
files directly, but there are plans to make this information available
via the command line tools like `go list -json`.

Fixes: #5555.

[1]: https://github.com/oss-review-toolkit/ort/blob/1dc5c54de3630f0f1249a7ec56ce0a3ba87ac5f1/downloader/src/main/kotlin/VersionControlSystem.kt#L361-L366
[2]: golang/go#44742 (comment)
[3]: golang/go#18387

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

The used '.info' files are available only as of Go version 1.19, see
golang/go#44742 (comment).

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

The used '.info' files are available only as of Go version 1.19, see
golang/go#44742 (comment).

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

The used '.info' files are available only as of Go version 1.19, see
also [1].

[1]: golang/go#44742 (comment).

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

This ensures that the `.info` files for all modules, which
get created by the Go command line tools under '$GOPATH/pkg/mod',
contain the VCS info. When using a Go proxy this is not guaranteed and
depends on the actual proxy instance, see [1]. This comes at the price
of increased execution time.

As the user's environment may likely be configured to use a GOPROXY,
which is the default, use an empty directory to not mix-up newly cached
files with already existing ones which might have been created using a
Go proxy and therefore may lack the VCS info.

This prepares for using the Go tooling to determine the VCS info instead
of using ORT's partial reimplementation of that.

[1]: golang/go#44742 (comment)
[2]: golang/go#18387

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

Prepare for reading the VCS info from '.info' files under
'$GOPATH/pkg/mod' which is available only as of Go version 1.19, see
also [1].

[1]: golang/go#44742 (comment).

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

Previously, ORT's GoMod integration had a rudimentary
(re-)implementation of the Go toolings' logic for resolving the VCS infos
for the dependencies, covering only the more common use cases. For
example, the implementation is VCS host specific and cannot handle mono
repository setup at all, without an ugly workaround in the downloader,
see [1]. Furthermore, I expect many not yet known issues in the more
uncommon use cases.

Avoid all these issue by just relying on the VCS info resolution of the
Go tooling.

Note that as of Go 1.19, the `.info` files under '$GOPATH/pkg/mod' are
guaranteed to contain the VCS info of the modules in case no Go proxy
is used [2]. For now that information is only accessible by parsing the
files directly, but there are plans to make this information available
via the command line tools like `go list -json`.

Fixes: #5555.

[1]: https://github.com/oss-review-toolkit/ort/blob/1dc5c54de3630f0f1249a7ec56ce0a3ba87ac5f1/downloader/src/main/kotlin/VersionControlSystem.kt#L361-L366
[2]: golang/go#44742 (comment)
[3]: golang/go#18387

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

Previously, ORT's GoMod integration had a rudimentary
(re-)implementation of the Go toolings' logic for resolving the VCS infos
for the dependencies, covering only the more common use cases. For
example, the implementation is VCS host specific and cannot handle mono
repository setups at all, without an ugly workaround in the downloader,
see [1]. Furthermore, I expect many not yet known issues in the more
uncommon use cases.

Avoid all these issues by just relying on the VCS info resolution of the
Go tooling.

Note that as of Go 1.19, the `.info` files under '$GOPATH/pkg/mod' are
guaranteed to contain the VCS info of the modules in case no Go proxy
is used [2]. For now that information is only accessible by parsing the
files directly, but there are plans to make this information available
via the command line tools like `go list -json` [3].

Fixes: #5555.

[1]: https://github.com/oss-review-toolkit/ort/blob/1dc5c54de3630f0f1249a7ec56ce0a3ba87ac5f1/downloader/src/main/kotlin/VersionControlSystem.kt#L361-L366
[2]: golang/go#44742 (comment)
[3]: golang/go#18387

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

This ensures that the `.info` files for all modules, which
get created by the Go command line tools under '$GOPATH/pkg/mod',
contain the VCS info. When using a Go proxy this is not guaranteed and
depends on the actual proxy instance, see [1]. This comes at the price
of increased execution time.

As the user's environment may likely be configured to use a GOPROXY,
which is the default, use an empty directory to not mix-up newly cached
files with already existing ones which might have been created using a
Go proxy and therefore may lack the VCS info.

This prepares for using the Go tooling to determine the VCS info instead
of using ORT's partial reimplementation of that.

[1]: golang/go#44742 (comment)
[2]: golang/go#18387

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

Prepare for reading the VCS info from '.info' files under
'$GOPATH/pkg/mod' which is available only as of Go version 1.19, see
also [1].

[1]: golang/go#44742 (comment).

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

Previously, ORT's GoMod integration had a rudimentary
(re-)implementation of the Go toolings' logic for resolving the VCS infos
for the dependencies, covering only the more common use cases. For
example, the implementation is VCS host specific and cannot handle mono
repository setups at all, without an ugly workaround in the downloader,
see [1]. Furthermore, I expect many not yet known issues in the more
uncommon use cases.

Avoid all these issues by just relying on the VCS info resolution of the
Go tooling.

Note that as of Go 1.19, the `.info` files under '$GOPATH/pkg/mod' are
guaranteed to contain the VCS info of the modules in case no Go proxy
is used [2]. For now that information is only accessible by parsing the
files directly, but there are plans to make this information available
via the command line tools like `go list -json` [3].

Fixes: #5555.

[1]: https://github.com/oss-review-toolkit/ort/blob/1dc5c54de3630f0f1249a7ec56ce0a3ba87ac5f1/downloader/src/main/kotlin/VersionControlSystem.kt#L361-L366
[2]: golang/go#44742 (comment)
[3]: golang/go#18387

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

This ensures that the `.info` files for all modules, which
get created by the Go command line tools under '$GOPATH/pkg/mod',
contain the VCS info. When using a Go proxy this is not guaranteed and
depends on the actual proxy instance, see [1]. This comes at the price
of increased execution time.

As the user's environment may likely be configured to use a GOPROXY,
which is the default, use an empty directory to not mix-up newly cached
files with already existing ones which might have been created using a
Go proxy and therefore may lack the VCS info.

This prepares for using the Go tooling to determine the VCS info instead
of using ORT's partial reimplementation of that.

[1]: golang/go#44742 (comment)
[2]: golang/go#18387

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

Prepare for reading the VCS info from '.info' files under
'$GOPATH/pkg/mod' which is available only as of Go version 1.19, see
also [1].

[1]: golang/go#44742 (comment).

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

Previously, ORT's GoMod integration had a rudimentary
(re-)implementation of the Go toolings' logic for resolving the VCS infos
for the dependencies, covering only the more common use cases. For
example, the implementation is VCS host specific and cannot handle mono
repository setups at all, without an ugly workaround in the downloader,
see [1]. Furthermore, I expect many not yet known issues in the more
uncommon use cases.

Avoid all these issues by just relying on the VCS info resolution of the
Go tooling.

Note that as of Go 1.19, the `.info` files under '$GOPATH/pkg/mod' are
guaranteed to contain the VCS info of the modules in case no Go proxy
is used [2]. For now that information is only accessible by parsing the
files directly, but there are plans to make this information available
via the command line tools like `go list -json` [3].

Fixes: #5555.

[1]: https://github.com/oss-review-toolkit/ort/blob/1dc5c54de3630f0f1249a7ec56ce0a3ba87ac5f1/downloader/src/main/kotlin/VersionControlSystem.kt#L361-L366
[2]: golang/go#44742 (comment)
[3]: golang/go#18387

Signed-off-by: Frank Viernau <frank_viernau@epam.com>

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.

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.

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.

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.

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.

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.

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.