Instead of removing it I would throw an error with basically your description if somebody tries to build the attribute.

Sounds good, do you know an example derivation that does that off the top of your head so I can see how to do that?

just search all-packages.nix for throw'

-1 for throw, since we already had errors saying it was broken.

Figured if we're not agree on removing it, or adding a throw, might as well update it and fix it.

It's still not working with sandbox, let me fix that.

@GrahamcOfBorg build bazel-deps

So, should we try upgrading it, remove, or just mark as broken?

I think we should remove it, but I'm happy for it to be upgraded, I just got stuck on this error:

src/main/tools/linux-sandbox-pid1.cc:427: "execvp(external/remotejdk11_linux/bin/javac, 0x42be70)": No such file or directory

I think I saw it on another bazel related derivation but I can't remember which one.

What I found out is in buildBazelPackage when we delete all the local repositories expecting Bazel to recreate them without network we don't support the remote jdk: that is because when the local jdk repository is recreated it cannot handle is the case of the remote jdk already having being downloaded.

This is broken due to bazelbuild/bazel#10280. I'm going to change the PR back to deleting this package.

I believe this can be fixed if you just tell bazel to use the local jdk provisioned within the nix build env
I have this in my .bazelrc file. Not sure how you would override this in the nix bazel build function call...

build --host_javabase='@local_jdk//:jdk'
build --java_toolchain='@bazel_tools//tools/jdk:toolchain_hostjdk8'