Description of the problem:
Bazel fails to resolve a toolchain if one of the constraint_values entries of the current platform is defined without a workspace prefix, while the exec_compatible_with of the toolchain uses the same constraint but with a workspace prefix. E.g. in rules_nixpkgs we define the constraint and platform in nixpkgs/constraints/BUILD.bazel as
constraint_value(
name = "nixpkgs",
constraint_setting = "@bazel_tools//tools/cpp:cc_compiler",
visibility = ["//visibility:public"],
)
platform(
name = "linux_x86_64_nixpkgs",
constraint_values = [
"@platforms//cpu:x86_64",
"@platforms//os:linux",
":nixpkgs",
],
visibility = ["//visibility:public"],
)
Note the constraint_values entry :nixpkgs without workspace prefix.
But in the toolchain we use
toolchain(
name = "toolchain",
toolchain = ":py_runtime_pair",
toolchain_type = "@bazel_tools//tools/python:toolchain_type",
exec_compatible_with = [
"@platforms//cpu:x86_64",
"@platforms//os:{os}",
"@io_tweag_rules_nixpkgs//nixpkgs/constraints:nixpkgs",
],
target_compatible_with = [
"@platforms//cpu:x86_64",
"@platforms//os:{os}",
],
)
Note the fully qualified constraint @io_tweag_rules_nixpkgs//nixpkgs/constraints:nixpkgs.
The WORKSPACE file does specify workspace(name = "io_tweag_rules_nixpkgs"), so those labels indicate the same constraint.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Checkout tweag/rules_nixpkgs@a897d1a and execute the following command
nix-shell --pure --run 'bazel test //tests:python-test --toolchain_resolution_debug'
The test should fail and the log should contain the following lines
INFO: ToolchainResolution: Looking for toolchain of type @bazel_tools//tools/python:toolchain_type...
INFO: ToolchainResolution: Considering toolchain @nixpkgs_python_toolchain//:py_runtime_pair...
INFO: ToolchainResolution: Toolchain constraint @bazel_tools//tools/cpp:cc_compiler has value //nixpkgs/constraints:nixpkgs, which does not match value @io_tweag_rules_nixpkgs//nixpkgs/constraints:nixpkgs from the execution platform @io_tweag_rules_nixpkgs//nixpkgs/constraints:linux_x86_64_nixpkgs
What operating system are you running Bazel on?
Ubuntun 19.10
What's the output of bazel info release?
release 2.0.0- (@non-git)
Also reproducible with 2.1.0.
If bazel info release returns "development version" or "(@Non-Git)", tell us how you built Bazel.
Using Nix with the following nixpkgs revision
{
"owner": "NixOS",
"repo": "nixpkgs-channels",
"branch": "nixpkgs-unstable",
"rev": "e4af779056318fa830de52080dca08464d0d2bf9",
"sha256": "0lnqr9lfavn89n66k48p8bcvcv0i2i84izwr5918qvq57dwzyjqm"
}
Have you found anything relevant by searching the web?
This seems related to the following issue #9177
Any other information, logs, or outputs that you want to share?
This is a regression, the issue was not observed in Bazel version 1.1.0.
Description of the problem:
Bazel fails to resolve a toolchain if one of the
constraint_valuesentries of the current platform is defined without a workspace prefix, while theexec_compatible_withof the toolchain uses the same constraint but with a workspace prefix. E.g. inrules_nixpkgswe define the constraint and platform innixpkgs/constraints/BUILD.bazelasNote the
constraint_valuesentry:nixpkgswithout workspace prefix.But in the toolchain we use
Note the fully qualified constraint
@io_tweag_rules_nixpkgs//nixpkgs/constraints:nixpkgs.The
WORKSPACEfile does specifyworkspace(name = "io_tweag_rules_nixpkgs"), so those labels indicate the same constraint.Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Checkout tweag/rules_nixpkgs@a897d1a and execute the following command
The test should fail and the log should contain the following lines
What operating system are you running Bazel on?
Ubuntun 19.10
What's the output of
bazel info release?Also reproducible with 2.1.0.
If
bazel info releasereturns "development version" or "(@Non-Git)", tell us how you built Bazel.Using Nix with the following nixpkgs revision
Have you found anything relevant by searching the web?
This seems related to the following issue #9177
Any other information, logs, or outputs that you want to share?
This is a regression, the issue was not observed in Bazel version 1.1.0.