incompatible_build_transitive_python_runfiles

[rickeylev]

To avoid performance issues with the upcoming Starlark implementation of the rules, the legacy behavior of py_binary targets that are only dependencies (not top-level requested targets) having their runfile symlinks materialized under bazel-bin is being disabled. This behavior has been undesirable since ~2017, but until now has been mostly harmless.

(More specifically, a performance issue (to the tune of 1% to 10% extra CPU usage) shows up because this behavior requires the Starlark rules to create an output that higher-level Starlark rule code also creates, which then causes the expensive "generate missing init.py files" logic to run multiple times as Bazel attempts to consolidate the actual actions to run).

Instead of relying on building one target to materialize files under bazel-bin for another target, users should explicitly specify the targets of interest. e.g., if you do this:

bazel build //foo
bazel-bin/bar

then you must switch to do this:

bazel build //foo //bar
bazel-bin/bar

(note to self: breaking changes policy)

[pcjanzen]

Will #14740 be merged as a prerequisite for this change? If not, won't it wildy exacerbate the problem in #11997?

[rickeylev]

Oh, thanks for pointing those out. Yes, that would exacerbate it. I'll have a look at #14740

[meteorcloudy]

https://buildkite.com/bazel/bazelisk-plus-incompatible-flags runs nightly, please add "migration-ready" label when you want the pipeline to test this incompatible flag.