x/vgo: Support optional fall back to "legacy" command line calls to git, bzr, hg, etc

[timshannon]

This may not be possible with the possible changes to $GOPATH handing in vgo, but if there was a flag or environment variable you could set to fall back to the old method of calling the git / bzr / hg executables, then it might allow for workarounds for issues like #24044 or for any case where you are hosting your instance of gitea gogs, etc.

It might also allow for a work around for the rate limiting issues in #23955.

[bradfitz]

Elsewhere I believe @rsc said that it was a design mistake to have the "go" command directly call the git/bzr/hg/svn executables, because that effectively requires either 1) all users to have all 4 tools installed, or 2) force the ecosystem to all use the same tool (e.g. git, like today). Good luck being a Go user wanting to put your source code up on the Internet with bzr. The ecosystem will be annoyed.

[timshannon]

True, and I complete agree with that going forward, however, having an optional flag / variable could ease the transition until suitable long-term workaround are in place for the scenarios referenced.

[andrewchambers]

Since we now embrace versions, we can also embrace version tarballs. lots of those tools can dynamically generate a tarball url for a given tag.

[rsc]

We're not going to fall back to the legacy version control tools, for the reasons Brad mentioned (also at https://research.swtch.com/vgo-module).

That said, I would be happy to support version control servers that are willing to speak simple HTTPS REST APIs to tell vgo what it needs to know (pretty basic queries plus fetch me a specific file or a tgz/zip at a given commit). I haven't looked into which ones do that.

Rest assured that we will find some way to make it easy to use local servers. We know the whole world isn't on GitHub.