Bazel 8.0.0rc2: autoload does not work with WORKSPACE repos

[gergelyfabian]

Description of the bug:

Testing Bazel 8.0.0rc2 I got such an error:

$ bazel build //...
Starting local Bazel server and connecting to it...
INFO: Invocation ID: 94b17434-9dc8-4f06-8612-54cdc65e5c92
WARNING: WORKSPACE support will be removed in Bazel 9 (late 2025), please migrate to Bzlmod, see https://bazel.build/external/migration.
WARNING: Couldn't auto load rules or symbols, because no dependency on module/repository 'protobuf' found. This will result in a failure if there's a reference to those rules or symbols.
WARNING: Couldn't auto load rules or symbols, because no dependency on module/repository 'rules_android' found. This will result in a failure if there's a reference to those rules or symbols.
WARNING: Couldn't auto load rules or symbols, because no dependency on module/repository 'rules_java' found. This will result in a failure if there's a reference to those rules or symbols.
WARNING: Couldn't auto load rules or symbols, because no dependency on module/repository 'rules_python' found. This will result in a failure if there's a reference to those rules or symbols.
WARNING: Couldn't auto load rules or symbols, because no dependency on module/repository 'rules_shell' found. This will result in a failure if there's a reference to those rules or symbols.
ERROR: /home/user/opt/bazel-scala-example/example-lib/BUILD:13:13: //example-lib:hello-world: no such attribute 'srcs' in 'java_library' rule
ERROR: /home/user/opt/bazel-scala-example/example-lib/BUILD:18:10: //example-lib:java_test: no such attribute 'test_class' in 'java_test' rule
ERROR: /home/user/opt/bazel-scala-example/example-lib/BUILD:18:10: //example-lib:java_test: no such attribute 'srcs' in 'java_test' rule
ERROR: /home/user/opt/bazel-scala-example/example-lib/BUILD:18:10: //example-lib:java_test: no such attribute 'deps' in 'java_test' rule
ERROR: package contains errors: example-lib
ERROR: package contains errors: example-lib: //example-lib:hello-world: no such attribute 'srcs' in 'java_library' rule
WARNING: Target pattern parsing failed.
ERROR: Skipping '//...': Error evaluating '//...': error loading package 'example-lib': Package 'example-lib' contains errors
ERROR: Error evaluating '//...': error loading package 'example-lib': Package 'example-lib' contains errors
INFO: Elapsed time: 2.845s
INFO: 0 processes.
ERROR: Build did NOT complete successfully

This worked with Bazel 7.3.2.

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Reproduction: https://github.com/gergelyfabian/bazel-scala-example/tree/bazel-8.0.0rc1

Simply run bazel build //... in this repo at branch bazel-8.0.0rc1

Which operating system are you running Bazel on?

Ubuntu 24.04

What is the output of bazel info release?

release 8.0.0rc2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

[email protected]:gergelyfabian/bazel-scala-example.git
b44d1811b34b69e28c30f99ec4b92c04b1ca93a5

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

Related: #23899

[gergelyfabian]

Moved here after initial clarification in #23899

[meteorcloudy]

@bazel-io fork 8.0.0

[meteorcloudy]

This should be fixed by 93b6265? @comius

[Wyverald]

gentle ping @comius

[comius]

Yes, it’s supposedly fixed. Needs to be verified.

[gergelyfabian]

How could I test it with e.g. bazelisk?

[meteorcloudy]

Just use the latest commit from https://github.com/bazelbuild/bazel/commits/release-8.0.0/
export USE_BAZEL_VERSION=d966638807f64cfa71ef0b16d6595a211f097f87

[gergelyfabian]

I got a different error, probably related to a too low rules_java version with this. Checking further.

[gergelyfabian]

I think this bug is fixed.

[gergelyfabian]

Even though I'd prefer to check another RC version as I have a hard time to get to a working state with my repo. My latest issue is a skyframe RuntimeException (after I have fixed my rules_java version, and ensured that rules_jvm_external setup is done correctly).

[meteorcloudy]

Thanks for the confirmation, we'll have rc3 hopefully today.

[iancha1992]

A fix for this issue has been included in Bazel 8.0.0 RC3. Please test out the release candidate and report any issues as soon as possible.
If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=8.0.0rc3. Thanks!

[gergelyfabian]

It's a bit hard to test this, as in my example repo I had new errors appearing for RC3.
For RC1 and RC2 the error was as in the bug report. For RC3 I got:

$ USE_BAZEL_VERSION=8.0.0rc3 bazel build //...
Starting local Bazel server and connecting to it...
INFO: Invocation ID: a28ef645-4019-42fc-b1a7-bba453881118
WARNING: WORKSPACE support will be removed in Bazel 9 (late 2025), please migrate to Bzlmod, see https://bazel.build/external/migration.
ERROR: Traceback (most recent call last):
	File "/home/user/.cache/bazel/_bazel_user/64527517dacf7170f7d914889f83481c/external/rules_java/java/defs.bzl", line 44, column 28, in <toplevel>
		java_proto_library = native.java_proto_library
Error: no native function or rule 'java_proto_library'
Available attributes: action_listener, alias, available_xcodes, bazel_version, bind, cc_binary, cc_import, cc_libc_top_alias, cc_library, cc_shared_library, cc_static_library, cc_test, cc_toolchain, cc_toolchain_alias, cc_toolchain_suite, config_feature_flag, config_setting, constraint_setting, constraint_value, environment, existing_rule, existing_rules, exports_files, extra_action, fdo_prefetch_hints, fdo_profile, filegroup, genquery, genrule, glob, java_binary, java_import, java_library, java_package_configuration, java_plugin, java_plugins_flag_alias, java_runtime, java_test, java_toolchain, label_flag, label_setting, local_config_platform, local_repository, memprof_profile, module_name, module_version, new_local_repository, objc_import, objc_library, package_group, package_name, package_relative_label, platform, propeller_optimize, register_execution_platforms, register_toolchains, repo_name, repository_name, starlark_doc_extract, subpackages, test_suite, toolchain, toolchain_type, xcode_config, xcode_config_alias, xcode_version
ERROR: Error computing the main repository mapping: at /home/user/.cache/bazel/_bazel_user/64527517dacf7170f7d914889f83481c/external/rules_java/java/repositories.bzl:20:6: at /home/user/.cache/bazel/_bazel_user/64527517dacf7170f7d914889f83481c/external/rules_java/toolchains/local_java_repository.bzl:17:6: initialization of module 'java/defs.bzl' failed

What version of rules_java should be used with Bazel 8.0.0?

Then I tried upgrading rules_java to 8.*. Only for rules_java 8.5.0+ it did not show me any more errors from rules_java itself, but then it showed me errors from rules_scala (that I guess should be adjusted to the Bazel 8.0.0 + rules_java changes).

My understanding of which error comes "before" or "after" another is probably lacking, so you could conclude from this feedback whether the original bug is fixed or not. I guess it is fixed (that is my gut feeling, but I cannot be sure).

[gergelyfabian]

I guess if I can see rules_java/rules_scala being used with a WORKSPACE repo means, that autoloading works.

[meteorcloudy]

@gergelyfabian Can you please test rc4?

[gergelyfabian]

@gergelyfabian Can you please test rc4?

Same thing as for RC3, I'm blocked by the incompatibilities of rules_scala vs. rules_java. I believe that is not a bazel bug, and this one should be fixed.

[mbland]

@gergelyfabian I've just posted my experimental results to bazelbuild/rules_scala#1652. Most of the Bazel 8 and rules_java 8 incompatibilities can be easily addressed once Bzlmodification lands, and what I think is the only remaining one may be resolved by a protobuf-java:4.29.0 release (without -RC2).

The tradeoffs are that users will be forced to upgrade to Protobuf v28.3 under Bazel 6 and 7, and Protobuf v29 under Bazel 8, and the load("@rules_java") statements required by Bazel 8 will break WORKSPACE users for good. Then again, that may be all the more reason to suggest folks migrate to Bzlmod sooner than later.

Update from bazelbuld/rules_scala#1652: I spoke too soon: I can get a WORKSPACE build to use rules_java 8.5.1 and the other updated repo versions, and get to the point where it reaches the Detected mismatched Protobuf Gencode/Runtime version suffixes error.

So it seems we could bump rules_scala to Bazel 8 and rules_java 8 without abandoning WORKSPACE, but we will abandon Bazel 6 and 7 at that point.

[gergelyfabian]

@gergelyfabian I've just posted my experimental results to bazelbuild/rules_scala#1652. Most of the Bazel 8 and rules_java 8 incompatibilities can be easily addressed once Bzlmodification lands, and what I think is the only remaining one may be resolved by a protobuf-java:4.29.0 release (without -RC2).

The tradeoffs are that users will be forced to upgrade to Protobuf v28.3 under Bazel 6 and 7, and Protobuf v29 under Bazel 8, and the load("@rules_java") statements required by Bazel 8 will break WORKSPACE users for good. Then again, that may be all the more reason to suggest folks migrate to Bzlmod sooner than later.

Update from bazelbuld/rules_scala#1652: I spoke too soon: I can get a WORKSPACE build to use rules_java 8.5.1 and the other updated repo versions, and get to the point where it reaches the Detected mismatched Protobuf Gencode/Runtime version suffixes error.

So it seems we could bump rules_scala to Bazel 8 and rules_java 8 without abandoning WORKSPACE, but we will abandon Bazel 6 and 7 at that point.

Thank you! This kind of confirms this bug can be closed.