Use core go lib/tooling for identify package metadata URLs instead of the Masterminds/VCS fork

[jeffwidman]

Is there an existing issue for this?

• I have searched the existing issues

Code improvement description

Today we fetch metadata information using github.com/Masterminds/vcs library:

dependabot-core/go_modules/helpers/importresolver/main.go

Lines 14 to 33 in 642f064

	func VCSRemoteForImport(args *Args) (interface{}, error) {
	remote := args.Import
	scheme := strings.Split(remote, ":")[0]
	switch scheme {
	case "http", "https":
	default:
	remote = "https://" + remote
	}
	local, err := ioutil.TempDir("", "unused-vcs-local-dir")
	if err != nil {
	return nil, err
	}
	repo, err := vcs.NewRepo(remote, local)
	if err != nil {
	return nil, err
	}
	return repo.Remote(), nil

However, that is a copy/paste of some code in core go, so we'd rather get direct access to the actual source. Further context:

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, and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some logic to handle that for a series of SCMs, and the Masterminds/vcs package does a similar thing 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?

I dug into this a little, and there's already an upstream request:

• cmd/go: provide a way to resolve an import path to a vcs, url, etc. golang/go#18387

Where someone noted:

This very functionality already exists, and has existed for a long time, in golang.org/x/tools/go/vcs package, under the func named RepoRootForImportPath.

Note that it correctly resolves a vanity import path to "https://github.com/rsc/pdf", and the repo root to "rsc.io/pdf". It's the same code that cmd/go uses for go get, just copied to another library where it can be imported.

However, it looks like the current plan is to deprecate that library:

• x/tools/go/vcs: deprecate, isolate, tag, and delete package golang/go#57051

I subscribed to golang/go#18387 and whenever it lands we should flip to that.

[jeffwidman]

There's a chance this may provide what we need:

• cmd/go: include vcs revision in module .info files 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 }

However, there is this caveat:

This is done. If you run with GOPROXY=off you will see them in all your info files that come from git.
If you are using a proxy then it depends on what the proxy serves.
By default Go uses proxy.golang.org, which serves the vcs info in info files it has gathered since Go 1.19 was released.
For example: https://proxy.golang.org/golang.org/x/build/@v/v0.0.0-20220810151148-671cb44b90c4.info
Older info files known to the proxy have not been refreshed, so you will see a mix of with and without vcs that way.

In the common case, this caveat shouldn't matter for us. Dependabot is only bumping to new versions, those are new to the proxy so they should have their metadata in the proxy. Only if someone turns on Dependabot on a repo with an old go module, and there's an update that is available but older than this change to the proxy, only then would we miss the metadata. That should be relatively rare.

So we'd want to doublecheck how we use the proxy and whether this would start breaking things