gopackagesdriver calls query which churns the analysis cache

[alexeagle]

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 between build and query.

Since gopackagesdriver does bazel query in the background, it can cause mysterious churning where users bazel build commands are slow, and then the gopackagesdriver is also slow, as they churn back and forth (in particular, debugging this just now, I saw go_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.

[voxeljorge]

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.

[aran]

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.

[voxeljorge]

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.

[aran]

With GOPACKAGESDRIVER_BAZEL_FLAGS set, and leavingsettings.json: "go.goroot": "${workspaceFolder}/bazel-${workspaceFolderBasename}/external/go_sdk", all external imports still fail for me. 🤷‍♂️

[DolceTriade]

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.

[voxeljorge]

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.

[DolceTriade]

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.

[fmeum]

Note that https://github.com/bazelbuild/bazel/issues/3054 will be resolved by 6.3.0, which may end up mostly solving this problem.