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
cmd/go: get transport failure unhelpful unless -v is used #12810
Comments
I received the same issue here with the error listed below. Go get is not using the proxy settings on my system which is behind an authenticating Windows proxy. If the software would just use the same proxy settings as IE (which is just one line of code in .NET), it would solve the problem. Obviously, you don't have that luxury here. F:\Documents\Go>go get -v golang.org/x/net/context |
I also experienced the same issue recently. We need better error reporting. |
It has a trivial fix but not a priority in my list. Removing my assignment and would be happy to see it's fixed by someone else. I am often coming across this issue. |
CL https://golang.org/cl/15756 mentions this issue. |
Hi, I have exactly the same issue : go get -v golang.org/x/net/context |
@msepehr, you don't describe your problem enough. Also, this is a closed issue. Please file a new bug. |
Today, if you execute go get on a package and it fails due to a connection timeout, the resulting error is too literal.
Recently, I was helping another developer who encountered this failure and was somewhat mystified as to the result:
They could reach other websites, etc. just fine so assumed that somehow Go itself must be broken or they typed the wrong path. However, when they talked to me, it was clear they were using the correct import path.
On a whim, I decided to use '-v' instead to see if that would be more helpful, and of course it became obvious what the likely failure was:
In this particular case, the issue was a misbehaving proxy that for some reason has problems with the forwarding in place, and once they used a different proxy, 'go get' succeeded.
I would like to suggest that if 'go get' fails due to a transport issue that the related transport errors should be printed; it's less likely to lead to failures that mystify users and generate unnecessary angst. I don't think it's fair to expect users to intuit that they should run again with '-v' for failures to get the actual errors. The current failure message, at the very least, can be misleading.
The text was updated successfully, but these errors were encountered: