[config] Find a better default for GOPATH ?

[JanKoehnlein]

The command line tools the go LS delegates to needs GOPATH to be defined correctly to find references across files. By default, it assumes GOPATH=<home>/go. If you have your workspace located elsewhere, find references and other services relying on it (code lens, call hierarchy...) will not work across file borders.

On the Go homepage they state "Go programmers typically keep all their Go code in a single workspace.". If that was true, a globally set GOPATH would suffice.

Nevertheless, in the IDE scenario it appears that you are more likely to work with a local GOPATH pointing to your workspace root. That is why vscode/go allows to set it in the config in various ways. Our Go LS supports exactly that, so you can override it in

• <home>/.go/go.json
• <wsroot>/go.json
• <wsfolder-root>/go.json (AFAIK, Theia does not support workspace folders yet,so this is 'for future use')

e.g.

{
    "inferGopath": true
}

Should we make that setting the default? I can imagine that it can also cause a lot of confusion for those users who stick to the Go recommendation. Go experts, what is your opinion?

[simark]

I don't really understand what is the expected typical scenario. I have set GOPATH in my .bashrc to point to ~/gopath, so that when I type go get ... to get packages, then end up there. My various go projects can then use the packages installed there, and they run fine. What I infer from what you are saying is that it's not the proper "go way". Instead, I should install all the dependencies for the various projects in these projects' folders. This would mean that every time I want to work on a different project, I have to set GOPATH to point to the base of that project. Is that right?

[JanKoehnlein]

That's how I read the recommendation on the Go-lang page. I cannot imagine that to be practical either. With one GOPATH per project that's what npm does: copy every dependency into each project. The alternative is the maven approach, with a single shared repository of dependencies, which has its problems as well. Did you try whether your scenarios work in VSCode with the original extension?

As the GOPATH can hold a list of directories, our default should maybe just append the workspace dir.

I am really not a Go expert, so I rely on your input here.

[simark]

That's how I read the recommendation on the Go-lang page. I cannot imagine that to be practical either. With one GOPATH per project that's what npm does: copy every dependency into each project. The alternative is the maven approach, with a single shared repository of dependencies, which has its problems as well. Did you try whether your scenarios work in VSCode with the original extension?

Does vscode have call hierarchy?

On my test case, when I try to find all references (in vscode) of the Times function (defined in other.go), it doesn't find any, even though it's used in test.go. So something tells me my setup is not right.

I tried the same thing, but now I have set GOPATH to my working directory, I get the same results.

As the GOPATH can hold a list of directories, our default should maybe just append the workspace dir.

I am really not a Go expert, so I rely on your input here.

I am not either, I never used Go for real. I was just told to try to improve the Go language server experience for our users :).

[JanKoehnlein]

There is no callhierarchy in VSCode. That's something Theia does better :-)
We use find references in CH and this its where it fails, so your observation seconds my assumption.

Maybe you can ask your Go users how they arrange their source code / libraries?

[colemickens]

Supporting the VS Code extension's inferGopath would be ideal. I've never had a situation where it failed to do the right thing.