Commit 91297a8
committed
Bump rules_java to 6.5.2
This fixes the previous failure by using the last `rules_java` 6
release. Its generated remote JDK repos contain the
`bootstrap_runtime_toolchain` target registered by the Bazel 7 legacy
`WORKSPACE` suffix.
The build now breaks with the following failure:
```txt
ERROR: error loading package '@@bazel_tools//src/main/protobuf':
cannot load '@@rules_python//python:proto.bzl': no such file
ERROR: external/com_frobozz_rules_magic/src/com/frobozz/magic/BUILD:3:12:
error loading package '@@bazel_tools//src/main/protobuf':
cannot load '@@rules_python//python:proto.bzl':
no such file and referenced by
'@@com_frobozz_rules_magic//src/com/frobozz/magic:EmitDigestsWorker'
ERROR: Analysis of target '//:hello' failed; build aborted:
Analysis failed
```
Like the previous commit, this is another case of legacy `WORKSPACE`
statement ordering producing a very difficult to diagnose build failure.
- Under Bazel 7, `@bazel_tools//src/main/protobuf` depends on
`@rules_python//python:proto.bzl`.
- In legacy `WORKSPACE` mode, Bazel 7 does _not_ instantiate the
`rules_python` archive that ships with it as a repo. (This is in
contrast with how it instantiates `rules_java_builtin` as described in
the previous commit.)
- In the legacy `bootstrap/WORKSPACE` file, `rules_proto_dependencies`
from `rules_proto` 5.3.0-21.7 instantiates a version of `rules_python`
that lacks this file.
- In the legacy `WORKSPACE` suffix, since a `rules_python` repo already
exists, the `maybe` statement for instantiating a newer `rules_python`
does nothing.
Under Bzlmod, Bazel declares `rules_python` as a `bazel_dep` and doesn't
need this explicit declaration. `bazel build --enable_bzlmod //...`
actually bypasses this error, but produces another error we'll fix
later.
Details of this specific breakage follow.
---
Bazel 7 updates `@bazel_tools//src/main/protobuf` to depend on
`@rules_python`.
- bazelbuild/bazel: Use real rules_python
bazelbuild/bazel@78729c0
The `@rules_python//python:proto.bzl` file first appeared in
`rules_python` 0.17.0:
- bazel-contrib/rules_python@0d3c4f7
- https://github.com/bazel-contrib/rules_python/blob/0.17.0/python/proto.bzl
The Bazel 7.6.2 distribution actually ships with `rules_python` 0.33.2.
- https://github.com/bazelbuild/bazel/blob/7.6.2/MODULE.bazel#L30
This archive isn't baked into a builtin repo like `rules_java_builtin`
described in the previous commit. Even so, the legacy `WORKSPACE` stanza
for Java rules, `jdk.WORKSPACE`, will try to load `rules_python` 0.24.0
via `maybe`.
- https://github.com/bazelbuild/bazel/blob/7.6.2/src/main/java/com/google/devtools/build/lib/bazel/rules/java/BUILD#L92
- https://github.com/bazelbuild/bazel/blob/7.6.2/workspace_deps.bzl#L49-L54
- https://github.com/bazelbuild/bazel/blob/7.6.2/src/main/java/com/google/devtools/build/lib/bazel/rules/java/jdk.WORKSPACE.tmpl
- https://bazel.build/versions/7.6.0/rules/lib/repo/utils#maybe
However, the `jdk.WORKSPACE` stanza is actually added to the legacy
`WORKSPACE` _suffix_. This renders the `maybe` a no-op if any other
legacy `WORKSPACE` statement instantiated any other version of
`rules_python`.
- https://github.com/bazelbuild/bazel/blob/7.6.2/src/main/java/com/google/devtools/build/lib/bazel/rules/JavaRules.java#L97-L98
As luck would have it, `rules_proto` 5.3.0-21.7 imports
`rules_python-4b84ad270387a7c439ebdccfd530e2339601ef27`, which predates
`rules_python` 0.0.1.
- https://github.com/bazelbuild/rules_proto/blob/5.3.0-21.7/proto/private/dependencies.bzl#L132-L139
- bazel-contrib/rules_python@4b84ad2
- https://github.com/bazel-contrib/rules_python/tree/4b84ad270387a7c439ebdccfd530e2339601ef27/python1 parent 0a5d939 commit 91297a8
1 file changed
+4
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
7 | 7 | | |
8 | 8 | | |
9 | 9 | | |
10 | | - | |
11 | | - | |
| 10 | + | |
| 11 | + | |
| 12 | + | |
| 13 | + | |
12 | 14 | | |
13 | 15 | | |
14 | 16 | | |
| |||
0 commit comments