Skip to content

--incompatible_autoload_externally=: Loading language specific rules removed from Bazel #23043

@comius

Description

@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.

Metadata

Metadata

Assignees

Labels

P2We'll consider working on this in future. (Assignee optional)incompatible-changeIncompatible/breaking changemigration-readyIncompatible flag is ready for migration with Bazel rolling releases or Bazel@last_greenteam-Rules-APIAPI for writing rules/aspects: providers, runfiles, actions, artifacts

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions