Feature request: Interpolate variables from workspace settings into extension settings

[mingp]

I am trying to write a VS Code workspace (.code-workspace) file that can be shared with my teammates and makes as few assumptions as possible. In order for the workspace config to be independent of where someone has checked out the repository, I use ${fileDirname} in the workspace config file to produce consistent file paths. This works in, for example, the folders config entry.

It appears that attempting to use variables in the Go extension settings, for example for go.gopath and go.goroot, does not work. Furthermore, it appears that the uninterpolated string is used directly as the value in question, which is not correct, and which expectedly fails.

It would be helpful for sharing workspace files if the Go extension's setting values interpolated variables just like the folders config. For example, I should be able to set go.gopath as ~/path/to/myproject/bin/go and go.goroot as ~/path/to/myproject/go.

This would be greatly beneficial. Thanks.

[hyangah]

With Go modules, setting go.gopath shouldn't be necessary in most cases. Go will continue to use GOPATH as a default location for module cache, and storage for build artifacts such as compiled binaries. However, it doesn't use it to store or find source code any more. And there is a discussion in the Go project about deprecating GOPATH. So, please avoid relying on it, setting it or including it in the shared setting.

go.goroot shouldn't be set in most cases either (with a couple of exception cases). Can you explain why setting/sharing go.goroot is needed?

For other settings, if variable replacement is necessary, please open issues.

[mingp]

@hyangah -

Thank you for responding.

Let me clarify about my project at work. I believe that it is one of the cases where go.gopath and go.goroot are necessary, although I agree with you that it is an uncommon configuration, and in many more common cases cases the defaults work quite well.

1. We have a monorepo, into which we vendor Go packages, into a subdirectory under the repo root. The repo is usually checked out somewhere under the user's home directory, although we don't enforce precisely where.
2. We use Bazel as our primary build tool. Bazel builds our artifacts, runs our tests, etc. Due to our build rules, Bazel, inside its build context, uses a vastly different directory structure than our repo. Bazel is set up correctly to populate a GOROOT appropriately. This part works fine as-is, but it does present a constraint that our editor setup must work with. That is to say, it would not be reasonable of us to expect or request the engineering organization to change its directory layout or development workflows to accommodate a single editor.
3. We do not use Go modules at present. It's unclear to me if a theoretical modules based setup would work, or how much effort it would take to get there. I don't understand Bazel well enough to say confidently. Suffice it to say, this is a big enough and disruptive enough change that this is realistically out of the question for the foreseeable future.
4. VS Code users represent a small proportion of overall engineers. That is to say, it would not be reasonable of us to expect or request that the overall Go setup change for the sake of support in a single editor.
5. (Edited to add:) We are on Go 1.12. That is to say that modules are available as opt-in, but not default, at this version (if I understand correctly). Upgrading the Go version is something that will happen in due time, but we would not expect this scenario to be the driver of it.

Where that leaves me is a setup like the following. (All names are made up, but structurally this is accurate.)

1. I have a home directory at /home/ming. I clone the monorepo to /home/ming/git/monorepo_project. But, I cannot rely on this. Perhaps my coworker (for the sake of example, Bob) clones the monorepo to /home/bob/work/repos/monorepo_project.
2. The Go subtree is rooted at /home/ming/git/monorepo_project/go. Inside here are both our team's code, as well as external code vendored into the tree.
3. I am trying to write a shared VS Code workspace at /home/ming/git/monorepo_project/dev/vs_code/workspace.code-workspace.

In order to make this work, I need go.gopath and go.goroot to resolve correctly. At present, I am hard-coding them, relative to my own home directory. That is to say, I'm setting, for example, go.goroot to /home/ming/git/monorepo_project/go, explicitly. This works fine for me. Where this breaks is for any other team member, who has a checkout of monorepo_project, but I don't know a priori where.

My proposed solution is to specify all paths relative to the ${fileDirname} of the workspace file, and then check the workspace file into the monorepo at a well known path. For example, if I know that the workspace file is at /home/ming/git/monorepo_project/dev/vs_code/workspace.code-workspace, then I can resolve the monorepo root, /home/ming/git/monorepo_project, as ${fileDirname}/../../../. Then, any other path I need to specify, can be specified relative to there.

(Edited to add:) For whatever it's worth, I gave the above details to try to illustrate how I find myself in the situation that I'm in. However, I think that situations like this are perhaps far more common than just this one. I suspect that any situation where a team enforces some assumptions about GOROOT, like checking it into version control as a smaller part of a bigger repo, but cannot fully enforce absolute paths, like requiring team members to use the same home directory structure, is going to run into this. Like, I think it's very possible to run into this without Bazel, for example.

(As another note, I would very much welcome if microsoft/vscode#70710 were implemented, which would make this much cleaner. Although, this is not necessary to make this work correctly, only clean it up significantly.)

[hyangah]

Thanks for sharing the specific setup scenario. It sounds like you are working with a single root workspace case. Doesn't ${workspaceFolder} or ${workspaceRoot} already work? The extension resolves this to the first folder path in the workspace.

The issue with `${fileDirname} is it has a specific meaning in VS Code (${fileDirname} - the current opened file's dirname), so potentially will cause issues in the future.

[mingp]

@hyangah -

Thank you for following up. Please allow me to clarify further.

Conceptually, we are working on a single monorepo, with a single root. The most intuitive mapping for this is to create a single root workspace with the monorepo root as the workspace root. In practice, we found that this causes performance issues. I'm not sure which component(s) slow down here, whether it is the VS Code indexer, and/or the language servers that we use, but the practical end result is that VS Code becomes unresponsive on operations like Cmd-click for navigating to a definition, and the status bar progress bar spins, until the operation appears to time out and get cancelled.

Whereas, if we configure a multi root workspace, with a list of individual projects that our team commonly works on, as individual directory entries under directories, then it appears that this is correctly constraining the indexers, and operations like Cmd-click for navigating to a definition all work as expected. This is the current configuration that we use, with each user having their own file, and hard-coded paths for each user's own setup.

I tried ${workspaceFolder}. As far as I can tell, in the multi root workspace case, this isn't what I want, as it varies depending on which configured directory I have open. Whereas, what I want is something that is invariant in relation to the workspace file itself, because the workspace file is known relative to the monorepo root, and everything else is known relative to that.

It's possible that ${fileDirname} is not the correct variable to be asking for. As far as I know, this proposed approach would work with anything that is invariant in relation to the workspace file and/or the repo that contains it. I think that we would be happy with any other variable that works that way.

Hope that clarifies. Thanks again.