Flip --legacy_external_runfiles to false

[lberki]

Motivation

This flag has been there since 2016 so we should make up our minds and I think it's better for everyone to do so.

Technically, it makes flipping --experimental_sibling_repository_layout somewhat more complicated since it makes the layout of the runfiles tree inconsistent with that of the execroot, but in practice, the plan is to flip them very close to each other temporally, so it doesn't matter much.

Description

This incompatible change changes runfiles trees: files in external repositories are currently available at both $RUNFILES/<main repo>/external/<external repo>/<path> and $RUNFILES/<external repo>/<path>. Flipping this flag removes the former.

The reason why the flag is not prefixed with --incompatible_* is that it predates that nomenclature.

Incompatible Flag

--legacy_external_runfiles

Migration Guide

If you are using the runfiles library, there isn't anything to do. If not, you'll have to update code to look for the files in their non-legacy location in the runfiles tree.

In particular, if --experimental_sibling_repository_layout is unset (which is the default), the path of source files in external repositories will be different between runfiles trees ($RUNFILES</repo name>/<repo-relative-path>) and the execroot (external/<repo name>/<repo-relative-path>). This means that some Make variables (e.g. $(JAVA)) cannot be used to reference the runfiles tree.

However, pseudo-Make variables ($(rlocationpath) and $(rootpath)) do work.

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

Bazel 8

Additional Context

No response

TODO List

No response

[peakschris]

How should we set up our .bazelrc files in the 7.3 series in order to prepare for this flip?

Is this correct?

common --nolegacy_external_runfiles
common --experimental_sibling_repository_layout

[meteorcloudy]

That is correct!

[fmeum]

Just a note: Flipping this separately from --experimental_sibling_repository_layout would make it more breaking as Make variables with exec paths (e.g. JAVA) would no longer work for runfiles discovery. Maybe Make variables should be called out in the migration notes?

[fmeum]

Referencing my reply to the other thread here: #23576 (comment)

[meteorcloudy]

@fmeum @lberki Continue the discussion about whether we should flip this flag or revert back to "legacy runfiles only" mode.

A quick test with Bazel's own test suite:

• flipping this flag, no test broken: https://buildkite.com/bazel/google-bazel-presubmit/builds/83431
• "legacy runfiles only" caused a lot of breakages: https://buildkite.com/bazel/google-bazel-presubmit/builds/83611

I think flipping this flag could still cause some downstream projects to break, but it's probably manageable, however, not the other way around.

[lberki]

@meteorcloudy that's a strong argument for flipping this flag instead of keeping the legacy paths. Should I send out a change?

[meteorcloudy]

@lberki I already have one, sending it to you

[meteorcloudy]

Closing this one since the flag is now flipped and there is no risk of rolling back.

[lberki]

🎉 Thanks for following through with this!