Loading language specific rules removed from Bazel

[comius]

Motivation

Language specific rules (Protos, Java, C++, Android) are being rewritten to Staralark and moved from Bazel into their rules repositories (protobuf, rules_java, rules_cc, rules_android, apple_support).

Because of the move the rules need to be loaded from their repositories. This requires adding load statements to all bzl and BUILD files that are using those rules.

Description

The flag --incompatible_autoload_externally accepts a list of rules or symbols (previously part of Bazel) that are automatically loaded from external repositories. For configuration see https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/packages/AutoloadSymbols.java.

Prefixing a symbol with '+', loads the symbol from rules_repository, but keeps the native implementation available in rules_repositories (redirects work). Symbol without a prefix is loaded and the native implementation is not available. Symbol prefixed with a '-' is not loaded and the native implementation is not available (same as if the symbol was deleted from Bazel).

Incompatible Flag

--incompatible_autoload_externally

Migration Guide

Bazel <=7:
TODO

Bazel 8:
The flag introduced incompatibilities because the rules are automatically loaded. For this to work we need to depend on the version of the rules_repostiories that implement the rules.

Required versions:
protobuf - 28.3
rules_java - 8.5.1
rules_cc - 0.0.17
rules_android - TODO
apple_support - TODO

With bzlmod the right version is selected automatically. Using WORKSPACE files, this needs to be done manually.

Bazel 9:
Load statements for all of the rules need to be added to BUILD and bzl files. To test the behaviour flag is set to an empty value, that is --incompatible_autoload_externally=

Cycles:
TODO

In which Bazel LTS version will this incompatible change be enabled?

Bazel 9

Additional Context

In Bazel 8, the flag will be set to the list of rules that are removed ==> rules are loaded automatically
In Bazel 9, the flag will be set to an empty list ==> rules are not loaded automatically anymore, load statements must be used

TODO List

With incompatible flag (highly recommend for incompatible changes having large impact):

• Implement the incompatible change at Bazel HEAD and guard it behind a flag.
• Backport the incompatible flag to the latest LTS release.
• Test the incompatible change with downstream projects and inform broken projects.
• Flip the incompatible flag at Bazel HEAD.
• Delete the incompatible flag and the old behavior at Bazel HEAD.

[tpasternak]

Would it mean they would be just loaded, or downloaded from BCR?

[tpasternak]

Just a few questions more:

1. Will it be possible to import locally defined symbols?
2. There are some rulesets mentioned above, I guess rules_python is missing

[limdor]

I just stumbled across this flag and I think it is good for migration but after reading some documentation I think in the current form is not very user friendly. Let me try to explain why and maybe you can let me know if you considered that.
If I understood correctly the Bazel vision, it means that in the final goal is to have all rules with the - prefix. However, this would require for a user to have internal knowledge on Bazel and knowing what rules are provided by Bazel.
Did you consider something more user friendly to treat all rules in the same way? For example incompatible_autoload_externally=-all or incompatible_autoload_externally=+all?

[limdor]

Just one more thing, I just tried with rules_cc doing the following
--incompatible_autoload_externally="@rules_cc"
but I cannot because it seems that some symbols are used by java tools

FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.IllegalStateException: Symbol 'CcInfo' can't be removed, because it's still used by: java_library, java_import, java_runtime, java_binary, java_common, JavaInfo

I then have to manually put all this also in the list like this
--incompatible_autoload_externally="@rules_cc,JavaInfo,java_import,java_library,java_runtime,java_binary,java_common,java_test,java_plugin"
But even then, it is still not working because it seems that rules_cc itself is not loading all symbols
ERROR: /home/limdor/.cache/bazel/_bazel_limdor/a313167c2de5a086f3a3e3c99789f007/external/rules_cc+/cc/common/cc_shared_library_hint_info.bzl:17:35: name 'cc_common' is not defined

Two questions.

• Is there a way to make this transitive? Meaning, I want to disable rules_cc, just disable whatever is needed also.
• And second, is this flag ready to be used by user? Is it only for some rules? It would be good to have a list of the rules that are ready and the ones that are not. From the description I deduced that for rules_cc should be ready but it seems that is not.

[jadenPete]

Question: What's the difference between this flag and --incompatible_stop_exporting_language_modules?