Commits on Apr 10, 2023

1. Replace custom go helper with go list …

   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](https://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 committed Apr 10, 2023
   Configuration menu

   • View commit details
   • Copy full SHA for feced2c
   • Browse repository at this point

   Copy the full SHA

   feced2c View commit details

   Browse the repository at this point in the history