GOPROXY environment not being passed #2026
Comments
Running Speaking of proxies, can you see if anything in https://code.visualstudio.com/docs/setup/network helps? |
|
What I see in So, the plugin is getting the environment variable, but it's not passed through to the child process, (this fails with ssl errors due to corp firewall): When I go to the terminal in VSCode and run the exact same command, it properly sees In regards to VSCodes networking related proxy settings, this is unrelated. Here is the documentation for |
The extension host process gets the same environment variables as what you saw in the console. The same are passed to the child process that runs Can you run the extension from source to see the exact environment variables being passed? Its is pretty straighforward.
|
|
I'm sorry for the delay, I was in SF for hashiconf. I didn't run from source, as I don't have nodejs, and corp laptop makes it hard. I just modified the transpiled source to include the following two lines inside roughly the same place you mentioned ( and the output is: As you can see, it's printing nothing after the prefix..: And yet, when I open debug tools in vscode, and print the environment variable, it's there:
What I'm wondering is if it's being stripped out before it's being passed to the extension. Maybe vscode strips anything that has proxy in the name, as it assumes it's related to the network proxy settings? In any case, it doesn't look like it's getting passed to the go executable, even though it's being passed to vscode, and vscode itself sees it. Can you replicate this? All it takes is to run the athens proxy docker container temporarily, and update your GOPROXY environment to point to it, so the athens proxy caches all of the downloaded go v1.11.x modules. |
|
Any update to this? |
|
Hey @lrstanley, Apologies, I didn't have time to try out athens myself. But by what you are sharing it looks like VS Code is getting the environment variable (because you see it in the integrated terminal), but it isn't passing it on to the extension host process that runs all the VS Code extensions (this is why you don't see it when you tried to print it out when you changed the source code). I am including @arschles in this thread who uses athens as well as VS Code. @arschles Have you seen anything like this before? @lrstanley One last thing I would like you to try is to run VS Code directly from the command line. Just type |
|
Yes, I have also invoked it from the command line, from the same environment where For @arschles -- note that this is solely for the portion where the vscode-go plugin attempts to |
And this is the same environment where |
|
Using Git Bash is how I usually invoke it on windows: liam@hostname MINGW64 ~
$ echo $GOPROXY
http://TRUNCATED.internal.com:3000
liam@hostname MINGW64 ~
$ go env GOPROXY
http://TRUNCATED.internal.com:3000Using command prompt though: C:\Users\liam>echo %GOPROXY%
http://TRUNCATED.internal.com:3000
C:\Users\liam>go env GOPROXY
http://TRUNCATED.internal.com:3000 |
|
Ok, so the "GOPROXY" environment variable is available in your Git Bash and command prompt, but when you run VS Code from either, it doesnt pass the same to the extension host. I have logged an upstream bug microsoft/vscode#65113 in VS Code. Lets see if someone there can help |
|
As a followup to what I mentioned in microsoft/vscode#65113; I think there may still be some issues in vscode-go, not vscode itself. @ramya-rao-a, you told me to use:
I made the modification in the generated plugin at I just tested again, trying to print all of Using In any case, I think I know what's going on. It looks like you're explicitly setting: envForTools['GO111MODULE'] = 'off';Which.. |
|
I suspect people using Or, maybe add an option to the extension to |
|
Good to know that the env variables are getting passed around properly. So to sum this up, since I disable module support when running
There have been other users who had these proxy issues in corporate environment before. Using the
We really don't want to get into a place where the tools need to be downloaded into more than 1 location |
Unfortunately, we cannot setup a proxy in this fashion. The only way is via a controlled environment through something like Athens for our usecase.
Which makes sense,, however, with the changes to go modules, Moving forward, might be better to focus on the use of I'm not saying what I recommended is the best option, but I do think it will become more of an issue, and warrants more discussion on alternatives. |
|
Filtering through the proposal a bit more, I do see:
Primarily:
So that is good at least -- though, there is still a usecase for |
|
Does running The reason why I disabled GO111MODULES when running Wont keeping GO111MODULES on result in the tools that dont use modules to fail the |
|
I was able to install all of them through Athens, if I ran the go get's myself (so I could keep golang/go#27215 (primarily this one) |
|
Why is that you dont see the same issue as #1919 when using Athens and GO111MODULE enabled? |
|
My guess is that When I see:
The first thing this makes me think there is a mismatch with tag/branch names, and what it finds for latest.. only a guess though. Modules should be backwards compatible with things that haven't been converted to a module yet, even for cases where the I've also used Artifactory's Golang support, and I believe it suffered from issues with Snippet from the docs: https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get
And, according to golang/go#27215 (comment), what the docs say doesn't actually work!
|
|
I have also met with this trouble. The environment $ go version
go version go1.13 windows/amd64
$ go env
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\xgf\AppData\Local\go-build
set GOENV=C:\Users\xgf\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\xgf\go
set GOPRIVATE=
set GOPROXY=https://gocenter.io
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\gopath\src\gitlab.sndaurl.cn\BackendDev\cwalarm\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\xgf\AppData\Local\Temp\go-build045237998=/tmp/go-build -gno-record-gcc-switchesWhen I do it myself, however, it works. $ go get -u -v -d github.com/stamblerre/gocode
go: finding github.com/stamblerre/gocode latest
go: downloading github.com/stamblerre/gocode v0.0.0-20181128172141-22843d89bc5a
go: extracting github.com/stamblerre/gocode v0.0.0-20181128172141-22843d89bc5a
go: finding golang.org/x/tools latest |
|
Tool installation should work as expected with the beta version of the extension, if anyone would like to try it out and confirm. |
|
@stamblerre I just tested the beta.5 version in your link and it works wonders. |
|
@lrstanley & @xgfone, Can you try the latest beta version of this extension and see if you still have issues? |
|
Hi @ramya-rao-a, I have tried version 0.11.8-beta.3 but it still won't recognize GOPROXY setting. |
|
@randalvance Can you open a new issue, share your Go related settings and provide details on the issue you are seeing? |
I'm not use to running on Windows, so excuse me if it's something specific I have to do on Windows.
Using the latest version of vscode-go, 0.6.92, I am seeing that the builtin functionality to install the analysis tools, the GOPROXY environment variable which is globally defined on windows, (and passed to vscode), isn't being passed when this library executes go.exe. When I start a terminal inside of vscode, it gets picked up as expected..
Trying to download modules through the Athens proxy, it is still throwing certificate errors when hitting Github (corp firewall restrictions). When doing it through the terminal, it downloads just fine.
Is there a way to get the go plugin to run 'go env' to see what environment variables it's getting passed?
Would also be worth while to add an additional setting for this as well (to override
GOPROXY, much likeGOROOTandGOPATH) -- I expect withGOPROXYmaking it much easier for corporations with restricted firewalls to use Go, this will be a frequently requested feature.The text was updated successfully, but these errors were encountered: