Enabling repo_mapping for the internal @bazel_tools

[diegomarquezp]

Hi from googleapis/google-cloud-cpp.
In order to be compatible both with bzlmod and WORKSPACE, we had to use the @com_google_protobuf name across our build files because @bazel_tools internally references this old name for protobuf and there seems to be the only name we can use to override its version. Is there any plan to enable repo_mapping inside @bazel_tools in WORKSPACE mode despite the soon deprecation?

Reference:

diegomarquezp:google-cloud-cpp$ bazelisk query --google_default_credentials --noenable_bzlmod --enable_workspace 'somepath(//google/cloud/storage:google_cloud_cpp_storage_grpc, @com_google_protobuf//src/google/protobuf:arena)'
//google/cloud/storage:google_cloud_cpp_storage_grpc
@googleapis//google/storage/v2:storage_cc_proto
@bazel_tools//tools/proto:cc_toolchain
@com_google_protobuf//:cc_toolchain
@com_google_protobuf//src/google/protobuf:protobuf
@com_google_protobuf//src/google/protobuf:micro_string
@com_google_protobuf//src/google/protobuf:arena

[meteorcloudy]

This is no longer possible at HEAD since WORKSPACE has already been deleted.

In older Bazel release branches, like 7.5.0, we do use repo_mapping for bazel_tools for other purposes:

bazel/src/main/java/com/google/devtools/build/lib/bazel/rules/tools.WORKSPACE

Line 4 in 6cfbf10

repo_mapping = {"@rules_java" : "@rules_java_builtin"}

However, I guess bazel_tools is not the only one that needs to be fixed for dropping com_google_protobuf, my feeling is it's better to keep using this until you can drop WORKSPACE support (hopefully with the deprecation of Bazel 6 later this year?)

[diegomarquezp]

Thanks, we'll stick to our workaround for the time being then.