Cleanup duplicate code by standardizing on one way - maybe eliminate native helper for go?

[jeffwidman]

Now that #4434 landed,
the only reason for the native go helpers is

dependabot-core/go_modules/lib/dependabot/go_modules/path_converter.rb

Lines 17 to 20 in 9060bc4

	SharedHelpers.run_helper_subprocess(
	command: NativeHelpers.helper_path,
	function: "getVcsRemoteForImport",
	args: { import: import_path }

However, looking at that file, I noticed that right after that function there's
another variant of git_url_for_path that is implemented in pure ruby so doesn't
require the native go helper:

dependabot-core/go_modules/lib/dependabot/go_modules/path_converter.rb

Lines 25 to 28 in 9060bc4

	# Used in dependabot-backend, which doesn't have access to any Go
	# helpers.
	# TODO: remove the need for this.
	def self.git_url_for_path_without_go_helper(path)

Weirdly it says the dependabot backend doesn't have access to go, which
certainly isn't true, otherwise the code removed by #4434 wouldn't have been
added in the first place.

So it'd be best to standardize on one of these two functions and remove the other to reduce confusion.

The tradeoff here appears to be that the pure ruby func would be simpler and allow
completely eliminating the native go helpers, but according to the code comment is less robust. However, the robust comment may be a red-herring, since it is a leftover from the go dep days, before go modules was the "one true way".

I have no opinion on which is the better way to go here, just that having two methods doing
the same thing with misleading code comments is definitely not the right way! 😄

[jurre]

Yeah, agreed. I think that the native version handles more than just git repo's (mercurial/svn etc) and the ruby version does only git. I am doubtful that Dependabot currently handles non-git sources well, and I wonder if switching to the pure ruby version would break any existing functionality but it's definitely worth a short investigation

[jeffwidman]

To move this forward, can I just put up a PR switching to the pure ruby version and see if any tests break? Or is this something that needs to be investigated on your side because breakage would most likely be internal/invisible to external contributors?

[jeffwidman]

Digging into this more, and took me a while to find the historical commits due to multiple file renames/re-orgs:

1. Initial commit rewriting the Ruby helper in Go: 43be2e1
2. Follow-on commit adding back the Ruby helper: bd4a9c0

There's no information on what motivated the initial rewrite in Go... this commit may be the root cause, but I'm not really sure:

Go: Use go-get=1 trick to find git source URLs for unrecognised names

as that's where I first see a mention of the code comment:

# TODO: This is not robust! Instead, we should shell out to Go and use
# https://github.com/Masterminds/vcs.

I'm checking internally for more info.

[jeffwidman]

I heard back from one of the original authors:

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?

[jeffwidman]

Note to myself: File a ticket with upstream go, asking them to expose the logic that does this so tools like Dependabot can easily repro it.