incompatible_use_platforms_repo_for_constraints: Don't use constraints from @bazel_tools, use @platforms instead

[hlopko]

Available since: 0.28
Tracking issue: #6516

Motivation

Bazel currently provides common constraints for platforms and toolchains in @bazel_tools//platforms. We are migrating these out of the Bazel binary to a principled, standalone repository over at https://github.com/bazelbuild/platforms which can be released independently from the Bazel binary and which defines a process for adding more constraints.

Migration

Ideally, declare an explicit dependency on https://github.com/bazelbuild/platforms, name the repository as @platforms, and use constraints from this repository. In cases where you cannot depend on https://github.com/bazelbuild/platforms (please tell us the reason in the comment), you can use the snapshot of https://github.com/bazelbuild/platforms in Bazel - Bazel implicitly provides this repository for Bazel's needs.

The actual migration in BUILD files is simple - use @platforms//setting:value instead of @bazel_tools//platforms:value:

sed 's$@bazel_tools//platforms:(linux|osx|windows|android|freebsd|ios|os)$@platforms//os:\1$' -E -i **/*
sed 's$@bazel_tools//platforms:(cpu|x86_32|x86_64|ppc|arm|aarch64|s390x)$@platforms//cpu:\1$' -i -E **/*

[dslomov]

What is the status of this for 1.0?

[hlopko]

Not flipping in time for 1.0

[smolkaj]

What's the status on this?
It seems that many teams are not upgrading to Bazel 6 since it breaks their build due to this issue.
My team included.

[aiuto]

What is breaking in you build? Is it because some rules still depend on bazel providing platforms via bazel_tools? There is some indication of that in the linked protobuf issue, but that seemed to wither on the vine as inconclusive.

@aranguyen Do you know of anything that is breaking downstream?

To be clear, any fix involves moving the ecosystem to rely on @platforms rather than @bazel_tools.

[smolkaj]

For one, it is braking protobuf's build, and we depend on protobuf: protocolbuffers/protobuf#12509

[aranguyen]

@aiuto All downstream projects that are tracked by our CI are all green. For other untracked projects, users need to migrate their code away from using contraints from bazel_tools.

protocolbuffers/protobuf#12509 (comment) mentioned that https://github.com/protocolbuffers/protobuf is green and the error doesn't seem to be related to this flag. Have you tried updating your protobuf dependency to latest version which should have been migrated.

[aiuto]

Now that the flag is in the graveyard. Can you delete tools/platforms/...
I'm not sure if there is a distinct issue for that, but it should happen before bazel 7.

[mgarbade]

This is breaking my build. I was trying to compile an older version of MediaPipeUnityPlugin (which I was able to do successfully 2 years ago) and now I'm getting into a dependency hell, apparently due to the above change.

What is the point of having bazel to fight against the dependency hell and then changing bazel itself throwing people into another dependency hell?

Anyway. I changed the following line in my WORKSPACE file:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

by

load("@platforms//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "platforms",
    url = "https://github.com/bazelbuild/platforms/archive/v3.7.2.tar.gz",
    # The VERSION here is a guess, as I don't know what exact version to use for the project.
)

it does not compile giving me the following error:

E:\Git\Homuler\mpup_v0.6.2_p3>python build.py build --desktop cpu --opencv=cmake -v
INFO (build.py): Building protobuf sources...
DEBUG (build.py): Running `bazel --output_user_root C:/_bzl build -c opt --action_env PYTHON_BIN_PATH=C://Users//garbade//.pyenv-win//shims//python //mediapipe_api:mediapipe_proto_srcs`
ERROR: Failed to load Starlark extension '@platforms//tools/build_defs/repo:http.bzl'. 
Cycle in the workspace file detected. This indicates that a repository is used prior to being 
defined.The following chain of repository dependencies lead to the missing definition.
- @platforms
This could either mean you have to add the '@platforms' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
ERROR: Error computing the main repository mapping: cycles detected during computation of main repo
mapping
Loading:
Traceback (most recent call last):
File "E:\Git\Homuler\mpup_v0.6.2_p3\build.py", line 392, in <module>
Argument().command().run()
File "E:\Git\Homuler\mpup_v0.6.2_p3\build.py", line 109, in run
self._run_command(self._build_proto_srcs_commands())
File "E:\Git\Homuler\mpup_v0.6.2_p3\build.py", line 51, in _run_command
return subprocess.run(command_list, check=True)
File "C:\Users\garbade\.pyenv\pyenv-win\versions\3.9.13\lib\subprocess.py", line 528, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['bazel', '--output_user_root', 'C:/_bzl', 'build', '-c', 'opt', '--action_env', 'PYTHON_BIN_PATH=C://Users//garbade//.pyenv-win//shims//python', '//mediapipe_api:mediapipe_proto_srcs']' returned non-zero exit status 37.                                                                                                                                                                  ```

[aiuto]

What is the point of having bazel to fight against the dependency hell and then changing bazel itself throwing people into another dependency hell?

That's a good question, and I appreciate that this is difficult for some users. That is one of the reasons this has taken so long to roll out. This particular change is specifically to decouple bazel versions from the ability to build for new hardware. Let's say Bazel 6 had a set of CPUs built in based on what was made in 2022, and rules depend on that version of platforms. You want to use Bazel 6 for a 5 year long project, but new hardware keeps being developed. So you want to build the 3rd generation of your device with a new RISC-V variant. You don't want to have to update Bazel to pick up a new CPU name. Instead, you just want to pick up a new version of platforms.

[martis42]

I am quite happy Bazel is performing breaking changes. Imho the workflow based on incompatibility flags is working well and giving each project the possibility to adjust in its own pace.
I am working a lot with C++ and would hate to see Bazel running into the same problem of ever growing complexity and need for best practices and linters just because nothing is ever deprecated.

[mgarbade]

• If I grep for "bazel_tools//platforms" in my clean project. I does not find anything
• once I start building with bazel the above mentioned error (Constraints from @bazel_tools//platforms have been removed) appears
• checking with "grep" all files containing the string "bazel_tools//platforms" are in a newly created folder called ".cache" so it's been created during build process

I guess there is not point in find/replace anything inside these cache files. I have to make it earlier, I guess.

Can someone tell me how to fix this?

Are there some lines I should add to WORKSPACE to avoid these deprecated .cache files from being checked out?

[aranguyen]

@mgarbade sorry I missed this message. You can try doing the following to see where in your project still depends on @bazel_tools//platforms

1. bazel build --nobuild <~target>
2. bazel info output_base - this step should give you the path to your build output directory
3. grep -r "@bazel_tools//platforms" <~output-from-step-2>

Example output from 3:

/private/var/tmp/_bazel_aranguyen/6e8429b404ae33f1dc5940e048063ac1/external/bazel_toolchains/configs/ubuntu16_04_clang/1.0/bazel_0.13.0/msan/BUILD:        "@bazel_tools//platforms:autoconfigured",
/private/var/tmp/_bazel_aranguyen/6e8429b404ae33f1dc5940e048063ac1/external/bazel_toolchains/configs/ubuntu16_04_clang/1.0/bazel_0.13.0/msan/BUILD:        "@bazel_tools//platforms:arm",
/private/var/tmp/_bazel_aranguyen/6e8429b404ae33f1dc5940e048063ac1/external/bazel_toolchains/configs/ubuntu16_04_clang/1.0/bazel_0.13.0/msan/BUILD:        "@bazel_tools//platforms:android",
/private/var/tmp/_bazel_aranguyen/6e8429b404ae33f1dc5940e048063ac1/external/bazel_toolchains/configs/ubuntu16_04_clang/1.0/bazel_0.13.0/msan/BUILD:        "@bazel_tools//platforms:x86_64",

You can see in the example that it tells me in bazel_toolchains there was still dependency on @bazel_tools//platforms so you can fix those.

[cleebp]

Ran into this error (below) when building the tensorflow suite of packages with conda, if you hit this when trying to bazel build tflite-support specifically (latest source) just make sure to use bazel<6.

ERROR: /home/user/.cache/bazel/_bazel_user/0e16d8232bb98776571a500cc0c256cb/external/bazel_tools/platforms/BUILD:64:6: Analysis of target '@bazel_tools//platforms:ios' failed

[yjianpen]

This breaks my repo: /private/var/tmp/_bazel_javieryu/aa8e4725bf9c05d07d76211f768b2ac1/external/local_execution_config_platform/BUILD:17:9: no such package '@@bazel_tools//platforms': BUILD file not found in directory 'platforms' of external repository @@bazel_tools.

Any idea to find where this error message come from?

[katre]

From the error, looks like the problem is local_execution_config_platform/BUILD. I don't know what defines this, you'll need to check your WORKSPACE or MODULE.bazel file and see.