Analysis Tools Missing warning is shown incorrectly when multi-workspace GOPATH is used

[lukehoban]

The logic for determining whether all tools are available is not taking into account that GOPATH may contain multiple workspaces.

See discussion in #10.

[mishak87]

There should be loop checking for each path in getGOPATHWorkspaces.

[ulrichSchreiner]

hi,

i'm currently working on a docker-container (vsc, somthing like atocker) which bundles all binaries in the container and starts vscode. The GOPATH is the current working directory of the host and the docker run ... mounts this directory as a GOPATH to the container.

It would be great to fix this bug to support multiple GOPATH entries in your setupGoPathAndOfferToInstallTools function so i can create a GOPATH in the container with two parts (one for the source, the second for the tools). So all the tools would be hidden from "outside" the container.

Imho it would be more better to have all the build-tools in the PATH, not in the GOPATH. It would be much easier to separate the build-tools from the workspaces. Would this be an option?

[mishak87]

@ulrichSchreiner When this is fixed you can always install them globally manually.

[ulrichSchreiner]

@mishak87 I don't think so. All the tools are referenced via GOPATH entries in the bin subdirectory, never in the PATH. So "install them globally manually" won't help if they won't be found :-)

[mishak87]

@ulrichSchreiner Gotcha! I will try to make pull request over weekend to get this fixed.

[lukehoban]

Thanks to @pcmind for PR #46 which fixed this issue.

[lukehoban]

@ulrichSchreiner and @mishak87 Good scenario. Would love a PR to support this. Feel free to open another issue as well if you'd like to continue to track this.

@ulrichSchreiner To your first point, we preferred GOPATH/bin over PATH just because we saw a number of developer setups where PATH was not configured to include GOPATH/bin. That said, perhaps it makes sense to search PATH as well when looking for the tools? Probably as a fallback after looking in the workspaces GOPATH/bin.

There's another approach to all of this which is just to have the VS Code Go extension install it's own known copies to a seperate location and use them from there instead of relying on PATH/GOPATH. Tracking that suggestion in #5, thoughts on that welcome.