Open alexeagle opened 1 year ago
I can confirm that adding an --output_base
flag works around this issue for us. The way this issue materialized for us was that some editor integrations were invoking tools that were vendored in via bazel run
commands concurrently with the gopackagesdriver. This seemed to cause both ends to continually invalidate each other, which in turn caused gazelle to run over and over as @alexeagle mentioned.
Note: This is mentioned as the first "complication" here.
I tried, but I don't know how to get an alternate --output_base
to work with vscode. I put
export GOPACKAGESDRIVER_BAZEL_FLAGS="--output_base=.gpd"
in front of my gopackagesdriver.sh
and amended .vscode/settings.json: "go.goroot"
to point to "${workspaceFolder}/.gpd/external/go_sdk"
, but something else was needed as the editor integration failed to find all external imports.
Interesting, we did the same but we used the external/go_sdk
from our main output base (probably incorrectly). Things seem to still work just fine though.
With GOPACKAGESDRIVER_BAZEL_FLAGS
set, and leavingsettings.json
: "go.goroot": "${workspaceFolder}/bazel-${workspaceFolderBasename}/external/go_sdk",
all external imports still fail for me.
🤷♂️
Do you have ideas on how to deal with you have to run a bazel command once first (to create the .gpd/external/go_sdk dir)? Otherwise, when I open a clean repo, it says it can't find the go compiler and tools.
I'm assuming you're hitting some kind of a chicken and egg problem. When the editor boots it probably is looking for that external go_sdk which hasn't been set up yet so it'll fail right away and probably throw an error. We do see errors like this, we've just documented that you may need to bazel build a go target before editor completion will work correctly. There might be a nicer solution for this but in practice it really hasn't been much of an issue for us.
yeah, that's what we've done so far. One hack that I did was I made the tools/gopackagedriver.sh script also use the same output base so the go_sdk is downloaded when vscode runs that.
Note that https://github.com/bazelbuild/bazel/issues/3054 will be resolved by 6.3.0, which may end up mostly solving this problem.
Due to https://github.com/bazelbuild/bazel/issues/3054 it's nearly impossible to avoid a
.bazelrc
file having lines that affect the analysis cache betweenbuild
andquery
.Since gopackagesdriver does
bazel query
in the background, it can cause mysterious churning where usersbazel build
commands are slow, and then the gopackagesdriver is also slow, as they churn back and forth (in particular, debugging this just now, I sawgo_repository
repo rules having to re-run gazelle every time)I think the solution for most users is likely just to have gopackagesdriver use a distinct Bazel server by passing an
--output_base
flag to point to a separate folder. Maybe the resolution to this issue is just to better document the problem and that solution.