`--incompatible_enable_deprecated_label_apis`

[Wyverald]

Motivation

Several old Starlark APIs related to labels had confusing names and/or behavior. This change deprecates those old APIs in favor of new ones with clearer names and intent.

Description

When --incompatible_enable_deprecated_label_apis is set to False:

• native.repository_name() is removed. Use native.repo_name() instead, which has a shorter name, and doesn't include a leading @.
• Label.workspace_name is removed. Use Label.repo_name instead, which has a clearer name, and behaves identically as the removed field.
• Label.relative() is removed. It has never functioned well with repo mapping. Instead, use the new method Label.same_package_label(), alongside the existing native.package_relative_label() and Label().

Incompatible Flag

--incompatible_enable_deprecated_label_apis

Migration Guide

• native.repository_name() can be replaced with '@' + native.repo_name().
• Label.workspace_name can be replaced with Label.repo_name.
• Depending on the use case, Label.relative() can be replaced with:
  • if the argument is always a package-relative label (such as :foo), use Label.same_package_label('foo') instaed.
  • if you're trying to relativize a label string from the context of a package in a macro, use native.package_relative_label() instead.
  • if you're trying to relativize a label string from the context of the .bzl file containing the currently running code, use Label() instead.

The newer APIs are only available in 7.1.0+. If backwards compatibility is a concern, use hasattr().

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

Bazel 8

Additional Context

No response

TODO List

• [x] Implement the incompatible change at Bazel HEAD and guard it behind a flag. (https://github.com/bazelbuild/bazel/commit/1bcb68c6b7ce065ba884e6d6573bd87aebae4c3b)
• [x] Backport the incompatible flag to the latest LTS release. (https://github.com/bazelbuild/bazel/pull/20977)
• [ ] 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.

[fmeum]

I would like to get rid of workspace_root as well, with a suitably named replacement. Otherwise we would still have mentions of workspace stick around that would require another flag migration to get rid of.

[Wyverald]

What's a good replacement? exec_root or some such?

[fmeum]

I would say repo_root or repo_path. I would prefer the latter as File#root returns a special starlark type, not a string.

[fmeum]

Also, aren't most incompatible flags set up so that they are flipped from off to on? I could see a "disable" version of this being a better fit for .bazelrc files.

[meteorcloudy]

Based on the result of https://buildkite.com/bazel/bcr-bazel-compatibility-test/builds/349, this flag should be safe to flip.

[meteorcloudy]

This flag is already flipped in Bazel 8

[Wyverald]

This is a "negative flip" (unfortunately). So we'll need to flip its default value from True to False.

[meteorcloudy]

Oh, I see..

[meteorcloudy]

@Wyverald Testing with protobuf caused a Bazel crash:

https://buildkite.com/bazel/bcr-presubmit/builds/12672#01961fe5-d459-4038-b530-7ae166f889d7

[meteorcloudy]

https://buildkite.com/bazel/bcr-bazel-compatibility-test/builds/359

Looks like most modules are broken due to rules_python, which requires https://github.com/bazel-contrib/rules_python/pull/2626 as a fix, which is included since 1.3.0-rc1.

[meteorcloudy]

I'm removing migration-ready for now, since it breaks almost all modules.