-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bazel can't resolve "platforms" repository, despite explicit module dependency #17655
Comments
Not that I expected a particular fix to have landed, but I confirmed that the same symptoms arise with Bazel version 6.1.0. |
@Wyverald, you've been chasing "platforms"/module problems that sound similar to this one. Do you have any ideas as to what's at fault here? |
There's several issues at play here:
The proper fix here would be to address 1, which is apparently a rare enough case that nobody has run into it so far. I imagine the fix shouldn't be difficult. |
We hit 1 in our bzlmod migration as well but luckily I was able to move all repos over at once to sidestep it |
Filed #17689 for point 3. I'll see if I could get point 1 fixed soon. |
Is it possible to work around the first problem by loading the "platforms" repository in my WORKSPACE.bzlmod file in addition to depending on it as a Bazel module? I had thought that the "platforms" repository is somehow available automatically to things loaded through WORKSPACE files, but maybe that's not so when we have module support activated. |
It would be if you were using the WORKSPACE[.bazel] instead of the WORKSPACE.bzlmod file. The latter turns off all "magic" repos for WORKSPACE. Also note that you could explicitly load a |
For my own edification, I tried using
There the "distroless_base_nonroot" repository comes from |
@bazel-io fork 6.2.0 |
…dule's mappings Currently, we evaluate WORKSPACE (`WorkspaceFileFunction`) and WORKSPACE-loaded .bzl files (`BzlLoadFunction` with `BzlLoadValue.KeyForWorkspace`) with the repo mapping purely computed from previous WORKSPACE chunks. This is unlike BUILD-loaded .bzl files from WORKSPACE-defined repos (`BzlLoadFunction` with `BzlLoadValue.KeyForBuild`, which is the same as `RepositoryMappingFunction`), which take the mappings of the Bzlmod root module into account. This CL fixes that discrepancy by doing the same "repo mapping composition" everywhere. Fixes bazelbuild#17655 RELNOTES: Fixed an issue where WORKSPACE and WORKSPACE-loaded .bzl files couldn't see the Bzlmod root module's mappings when Bzlmod is enabled. PiperOrigin-RevId: 515318590 Change-Id: I4babc922f6cdb932d17ce18d9a9d9d427dbed2eb
…dule's mappings (#17818) Currently, we evaluate WORKSPACE (`WorkspaceFileFunction`) and WORKSPACE-loaded .bzl files (`BzlLoadFunction` with `BzlLoadValue.KeyForWorkspace`) with the repo mapping purely computed from previous WORKSPACE chunks. This is unlike BUILD-loaded .bzl files from WORKSPACE-defined repos (`BzlLoadFunction` with `BzlLoadValue.KeyForBuild`, which is the same as `RepositoryMappingFunction`), which take the mappings of the Bzlmod root module into account. This CL fixes that discrepancy by doing the same "repo mapping composition" everywhere. Fixes #17655 RELNOTES: Fixed an issue where WORKSPACE and WORKSPACE-loaded .bzl files couldn't see the Bzlmod root module's mappings when Bzlmod is enabled. PiperOrigin-RevId: 515318590 Change-Id: I4babc922f6cdb932d17ce18d9a9d9d427dbed2eb Co-authored-by: Googler <[email protected]>
…dule's mappings Currently, we evaluate WORKSPACE (`WorkspaceFileFunction`) and WORKSPACE-loaded .bzl files (`BzlLoadFunction` with `BzlLoadValue.KeyForWorkspace`) with the repo mapping purely computed from previous WORKSPACE chunks. This is unlike BUILD-loaded .bzl files from WORKSPACE-defined repos (`BzlLoadFunction` with `BzlLoadValue.KeyForBuild`, which is the same as `RepositoryMappingFunction`), which take the mappings of the Bzlmod root module into account. This CL fixes that discrepancy by doing the same "repo mapping composition" everywhere. Fixes bazelbuild#17655 RELNOTES: Fixed an issue where WORKSPACE and WORKSPACE-loaded .bzl files couldn't see the Bzlmod root module's mappings when Bzlmod is enabled. PiperOrigin-RevId: 515318590 Change-Id: I4babc922f6cdb932d17ce18d9a9d9d427dbed2eb
Description of the bug:
Per discussion in the "bzlmod" channel of the "Bazel" Slack workspace, and possibly related to #17289, when I try to use rules_oci's
oci_image
rule in a root module (that is, in a Bazel workspace with a MODULE.bazel file and with the--enable_bzlmod
flag active), building the target fails due to Bazel claiming that there is no repository named "platforms" defined:This error arises even when I have the following function call in my MODULE.bazel file, referring to the "platforms" module:
If I don't mention the "platforms" module's repository explicitly anywhere in my code and remove that entry from my MODULE.bazel file, then Bazel fails differently, though this is not the root of my complaint here:
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Please find attached here an archive of a Bazel repository, with a root module named "bzlmod_platforms_test." In the WORKSPACE.bzlmod file, it uses rules_oci's
oci_pull
rule to pull an OCI image from the distroless project.In the "test" package, there's a tiny shell program named greet.sh, packaged into a tar archive by pkg_tar, and then used as the content of an OCI image in the "image" target by way of the
oci_image
rule.Unpack that archive, and attempt to build the "test:image" target.
tar zxf bzlmod-platforms-test.tar.gz cd bzlmod-platforms-test bazel build //test:image
Observe that the build fails for lack of the "platforms" repository (nominated in the error message as "@platforms").
Which operating system are you running Bazel on?
macOS 13.2.1
What is the output of
bazel info release
?release 6.0.0
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?No response
Have you found anything relevant by searching the web?
The use of rules_oci and pkg_tar is based mostly on @alexeagle's bazel-contrib/rules_oci#77, simplified here to show that I'm not even using the "platforms" module explicitly in my own code. In the real repository in which this problem arose, I am using that module explicitly in various places, but I wanted to show that I was unable to use pkg_tar and rules_oci together both with and without a dependency on the "platforms" module. In other words, while the error message makes it look like I'm missing a dependency, expressing that dependency explicitly doesn't help.
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: