Setting output_base causing issues with http_archive related rules

[elklein]

The on demand download rules wind up downloading to paths outside of output_base, which causes all sorts of bad behavior when "Queries Share Server" is not selected (and that setting is off by default).

I've found that setting --output_user_root instead of --output_base (in bazel_query.ts) fixes the issue quite nicely.

I can put together a pull request for this if you'd like (if it's an acceptable solution to the issue).

[thomasvl]

Is this because you haven't done a build before so things are downloading for the first time while also doing queries?

Choosing the output base directly talks about using --output_base for queries. --output_user_root docs does seem to say it might isolate more, but it likely comes at the cost fo two complete copies of everything that has to be downloaded for the rules, and I'm not sure if that is good.

It might make more sense to see about running some other command to try and get the downloaded things resolved first so they can be shared after that.

[thomasvl]

@laurentlb do you have any suggestions here on what to do?

[elklein]

Yeah, I first thought this was because I wasn't pre-caching my repos, so I tried running the exact same command first without --output_base, and then again with --output_base. No matter what I did I was getting weird errors with http* rules and callstacks involving /DEFAULT.WORKSPACE.SUFFIX.

I'll try to grab some time to get back to this and repro it again and get more details.

I agree that the double installBase is bad, and should probably be avoided. It seems almost like there's some kind of bug with non-default outputBase and default installBase location.

[thomasvl]

Depending on what you find, it might make sense to open up an issue on bazel itself with your details and reference some of the docs referenced here because either things aren't working as expected, or those docs need some revisiting to cover the issues you are running into.

[elklein]

Ok. So, the error I get is this

bazel --output_base=/tmp/ee79067f914abe58284ab7a8abdc7f7d query ...:* --output=package
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
INFO: Call stack for the definition of repository 'rules_cc' which is a http_archive (rule definition at /tmp/ee79067f914abe58284ab7a8abdc7f7d/external/bazel_tools/tools/build_defs/repo/http.bzl:292:16):
 - /tmp/ee79067f914abe58284ab7a8abdc7f7d/external/bazel_tools/tools/build_defs/repo/utils.bzl:205:9
 - /DEFAULT.WORKSPACE.SUFFIX:302:1
ERROR: error loading package 'bazel-sdk/external/bazel_tools/third_party/jarjar': Label '//tools/jdk:remote_java_tools_aliases.bzl' is invalid because 'tools/jdk' is not a package; perhaps you meant to put the colon here: '//:tools/jdk/remote_java_tools_aliases.bzl'?

No error if I leave out --output_base or if I change to --output_user_root.

I don't think I have enough context to debug this further. My best guess is that the query is running inside the sandbox, and that by setting -output_base we're somehow putting installBase outside of that sandbox which is causing issues. That's a wild guess, but... ?

I'll go ahead post this to core bazel and see if they have ideas.

[elklein]

There is already an issue on this over there. Not exactly the same thing, but very, very close:

https://github.com/bazelbuild/bazel/issues/10653

[yev3]

I have the same issue using Bazel in vscode and found a workaround in https://github.com/bazelbuild/bazel/issues/10653#issuecomment-673077065 if that helps anyone.

[cameron-martin]

Looks like this is the same issue as #216. I think the correct fix is in Bazel. I've put up a PR here: https://github.com/bazelbuild/bazel/pull/21005

[cameron-martin]

Closing this as duplicate of #216. The fix will be in Bazel 7.1.0.