Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: cmd/go: support selecting a VCS transport #30304
Git supports multiple transports. The built-in transports are
With #26232, it will become possible to support private Git repositories with
Multiple workarounds exist for this problem.
Because of these workarounds, this problem is not critical. But it's nice if it's addressed.
Let users choose a VCS transport for
Idea 1 (add a query param for selecting a transport)
In addition to
A nice part of this option is that this is compatible with old/new client/server. A new server that supports this new query param can be compatible with the old go toolchains. When the new go toolchains that support
We can abuse GOAUTH mechanism for this purpose. GOAUTH is meant for auth, but users can add any HTTP header that is not related to auth. A user can write a GOAUTH program that adds a special HTTP header that specifies their VCS transport preference and a supported server can return a different go-import URL based on that.
Idea 2 (let the server return multiple go-import URLs)
Let servers return multiple go-import tags with a different transport. The go toolchains need to choose which one it uses.
This might lose the backward compatibility, so I'm not sure if this is a good option.
Idea3(local go get config for multiple VCS paths)
If there's a go get config
Because, env var
I think it's possible to allow the server to return multiple
So, if I understand correctly, we can add
The tricky part about multiple paths, I think, is attempting them in the right order. We can (and currently do) use
Per https://tip.golang.org/cmd/go/#hdr-Remote_import_paths, the
So perhaps the scheme-probing version could be something like:
For example, the tags returned for
<!--for new clients--> <meta name="go-import" content="github.com/golang/protobuf git https://github.com/golang/protobuf ssh://firstname.lastname@example.org/golang/protobuf"> <!--for older clients--> <meta name="go-import" content="github.com/golang/protobuf git https://github.com/golang/protobuf">
That would combine with
I think we should leave this alone. The fact that Git has lots of complexity does not require us to import that complexity into the go command.
If we are talking about servers with <meta> tags, presumably the server operator has some sense of the preferred transport. They can use that scheme in the URL in the <meta> tag. Users who for whatever reason disagree with that transport can use insteadOf.
I've gone through as many of the linked issues as I can find and want to make sure my understanding is correct:
It appears that this "proxy" declares such a minimal amount of data:
Was there already a discussion on just specifying this inside a config file or env vars like I do for gitconfig? Many of the repos I work on regularly are only available via ssh and have no public https endpoint. As the toolchain has got more complex and I'm trying to adapt to modules I don't have an alternative anymore for writing Go. It seems all Go programmers are expected to eventually run a local proxy server ... just to map a hostname to a git url (as done by my .gitconfig). I feel like this use case is common and handled perfectly in .gitconfig, I've managed to expand the simple rewriting for every configuration I've come across. It's small, concise and easy to maintain.
I understand that the proxy ship has probably sailed and will run it if I must, but I can't seem to find the code or how to run and configure it? Maybe there is another way for my simple use case of using my preferred VCS settings for obtaining code remotely?
Search for “.vcs suffix” in https://tip.golang.org/cmd/go/#hdr-Remote_import_paths. If we know that the module path is a VCS path, then we do try the VCS directly.
@bcmills Thank you for the suggestion, I noticed the link was for tip but I gave it a whirl anyways and was pleased to see the execve calls and it immediately downloaded the module. It does fail a check against the downloaded modules name as seen below:
Does the module need a git suffix as well, i.e.