-
Notifications
You must be signed in to change notification settings - Fork 17.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/vgo: use vcs tools instead of https APIs of code hosting sites #24915
Comments
Change https://golang.org/cl/107657 mentions this issue: |
Change https://golang.org/cl/107656 mentions this issue: |
Has there been any consideration given to the idea of allowing a command to be invoked in lieu of an HTTP proxy? E.g.:
In the minimal case, this would allow for use of tools such as In the more complex case, a script or program could be invoked and decide to use version control or other tools for certain domains. E.g. if #!/bin/sh
case "$1" in
rsc.io/*) curl -sSL "$1";;
code.corp/*) ssh code.corp -- cat "/some/corporate/repos/$1";;
*) echo >&2 "no fetching of 3rd party code: $1"; exit 1;;
esac Git's |
Why does it seem like the whole concept of URLs and URNs is being re-invented? URLs include b access protocol, and URNs provide a broadly understood concept of uniqueness. |
Drop API-based access to Bitbucket, Gerrit, GitHub, now that we can (again) talk directly to their Git repos. Also drop general LatestAt query in favor of plain Latest (at current time on default branch), which is all that we needed and all that makes sense when talking directly to Git servers. For golang/go#24915 (still need hg, svn, bzr, fossil). Fixes golang/go#23955 (no GitHub API calls, so no rate limits). Fixes golang/go#24085 (no GitHub API calls, so no 403 responses). Fixes golang/go#24076 (GitHub enterprise's go-get=1 pages are now OK). Fixes golang/go#24102 (no more canonical GitHub import path checks). Change-Id: I99fadb09a565398da3ec88f17691217aca7bf571 Reviewed-on: https://go-review.googlesource.com/107657 Run-TryBot: Russ Cox <[email protected]> Reviewed-by: Bryan C. Mills <[email protected]>
@lrewega At least to start, no, we don't plan to do that. Let's see how things go with just ordinary network-level proxy support instead of command-level. @sdwarwick, I don't understand what you're getting at. The notation here is the same as go get always has been. We're not changing that. |
A goal of introducing modules was to move away from invoking version control tools directly, but it has become clear that we're not ready to do that today. GitHub in particular imposes draconian limits on HTTPS API access that they don't impose on ordinary Git access. And we can avoid for now breaking company setups using private Git servers. Because GitHub Enterprise now serves ?go-get=1 queries in a way that is compatible with old go get, dropping back to version control tools makes that compatible with vgo too. The next CL hooks this code into the rest of vgo. For golang/go#24915. For golang/go#23955. For golang/go#24076. Change-Id: I76bea30081047ab68286a5d095a0d55872c5a1a3 Reviewed-on: https://go-review.googlesource.com/107656 Run-TryBot: Russ Cox <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Bryan C. Mills <[email protected]>
Could be possible to keep both http api and vcs to remove issues like #25102 and begin now to experiment with http api ? |
Does this mean that modules in private repos can be fetched over ssh? I am having trouble getting things to build that use private repos as dependencies. |
Everything is using git again. Not sure why this wasn't closed. @paulbdavis, The git invocations always specify https://. They don't fall back to ssh:https:// like old "go get" used to. If you need to avoid https:// my suggestion would be to use git's insteadOf configuration feature in your $HOME/.gitconfig, so that 'https://' is accepted and understood by git to mean ssh. |
@rsc thanks, I had tried this before, but that was before using vcs again. Are there any plans to continue to allow git+ssh access going forward? (via some env var, git config as above, fallbacks instead of failure, etc.). Without SSH, I am using a combo of vendoring, GOPROXY, and @myitcv's modpub, then compiling in the GOPATH with "vanilla" go in my CI. Tedious, but works so I can use vgo now. Going forward I would expect the proxy availability to be more robust for handling this use case, but simply allowing git+ssh to be available at least as an option would simplify using private git repos now and in the future (for git users at least). |
@paulbdavis to use git with ssh, you'll need a config setting along the lines of:
See https://git-scm.com/docs/git-config for more details. |
@rsc thanks, I had tried this before, but that was before using vcs again. Are there any plans to continue to allow git+ssh access going forward? (via some env var, git config as above, fallbacks instead of failure, etc.). Without SSH, I am using a combo of vendoring, GOPROXY, and @myitcv's modpub, then compiling in the GOPATH with "vanilla" go in my CI. Tedious, but works so I can use vgo now. Going forward I would expect the proxy availability to be more robust for handling this use case, but simply allowing git+ssh to be available at least as an option would simplify using private git repos now and in the future (for git users at least). |
@paulbdavis did you see my response #24915 (comment)? Looks like you reposted the same comment (#24915 (comment)) in response? |
Sorry, not sure how that got posted again four days later. Yes, I got git+ssh working as you described. What I am trying to ask is if using vcs or allowing vcs to be used is going to remain a part of vgo going forward into to 1.11 preview implementation. From reading the blog posts, eliminating vcs usage seems to be a goal. The use case of having private repositories is a fairly common one, and using vcs tooling makes it easy to get working on any machine that has your ssh keys versus making sure you have a working proxy set up for each set of private repos being used (for example, private libraries for multiple client projects) |
Great.
Yes, it will. Indeed per #24915 I quote:
|
In https://research.swtch.com/vgo-module I wrote that
We still do, but it seems clear that this will be a large burden especially for corporate users. It is probably better to separate the introduction of versioning from the imposition of this restriction. We can focus on making the migration to versioned packages as painless as possible and do drop version control tool support at some later date, if at all. (One possibility is that if we get a reliable global proxy then you'd have to explicitly ask not to use the proxy, at which point the security and fragmentation concerns are significantly lessened.)
The text was updated successfully, but these errors were encountered: