Skip to content
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

Closed
seh opened this issue Mar 2, 2023 · 9 comments
Closed
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug

Comments

@seh
Copy link

seh commented Mar 2, 2023

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:

bazel build //test:image
ERROR: Analysis of target '//test:image' failed;
       build aborted: no such package '@platforms//cpu':
       The repository '@platforms' could not be resolved: Repository '@platforms' is not defined

This error arises even when I have the following function call in my MODULE.bazel file, referring to the "platforms" module:

bazel_dep(name = "platforms", version = "0.0.6")

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:

bazel build //test:image
ERROR: /private/var/tmp/.../external/yq_toolchains/BUILD.bazel:12:10:
       no such package '@platforms//cpu':
       The repository '@platforms' could not be resolved:
       Repository '@platforms' is not defined and referenced by '@yq_toolchains//:darwin_amd64_toolchain'
ERROR: /.../bzlmod-platforms-test/test/BUILD.bazel:14:10:
       While resolving toolchains for target //test:image:
       invalid registered toolchain '@yq_toolchains//:darwin_amd64_toolchain':
       Analysis failed

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 returns development 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

@sgowroji sgowroji added type: bug team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. untriaged area-Bzlmod Bzlmod-specific PRs, issues, and feature requests labels Mar 2, 2023
@seh
Copy link
Author

seh commented Mar 6, 2023

Not that I expected a particular fix to have landed, but I confirmed that the same symptoms arise with Bazel version 6.1.0.

@seh
Copy link
Author

seh commented Mar 7, 2023

@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?

@Wyverald
Copy link
Member

Wyverald commented Mar 8, 2023

There's several issues at play here:

  1. Bzlmod currently has a restriction where during WORKSPACE evaluation, repos from Bzlmod aren't visible. Note that after WORKSPACE evaluation (e.g. in BUILD files and stuff), repos defined in WORKSPACE can properly see repos from Bzlmod. (see https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/skyframe/BzlLoadFunction.java;l=878-879;drc=e26a3a0ea6d2caf43e8e172a38d17d879e4ada4f)
  2. rules_oci's oci_pull repo rule is actually a WORKSPACE macro that uses labels like @platforms//:foo (https://github.com/bazel-contrib/rules_oci/blob/2e7ca44886f5dae977408c55f0a7be8743e6db08/oci/pull.bzl#L334). WORKSPACE macros are obviously run during WORKSPACE evaluation, so this triggers 1.
  3. The error message is very unhelpful. It doesn't tell you what triggered the attempt to load from @@platforms. I'll file a separate issue about this.

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.

@Wyverald Wyverald added P2 We'll consider working on this in future. (Assignee optional) and removed untriaged labels Mar 8, 2023
@keith
Copy link
Member

keith commented Mar 8, 2023

We hit 1 in our bzlmod migration as well but luckily I was able to move all repos over at once to sidestep it

@Wyverald
Copy link
Member

Wyverald commented Mar 8, 2023

Filed #17689 for point 3. I'll see if I could get point 1 fixed soon.

@seh
Copy link
Author

seh commented Mar 8, 2023

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.

@Wyverald
Copy link
Member

Wyverald commented Mar 8, 2023

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 platforms repo in WORKSPACE.bzlmod, but you'd then run into #17289 (comment).

@seh
Copy link
Author

seh commented Mar 8, 2023

For my own edification, I tried using http_archive to download the "platforms" repository in my WORKSPACE.bzlmd file, then tried to build an oci_image target. It failed like this:

ERROR: /private/var/tmp/<sandbox_dir>/external/distroless_base_nonroot/BUILD.bazel:1:6: configurable attribute "actual" in @distroless_base_nonroot//:distroless_base_nonroot doesn't match this configuration. Would a default condition help?

Conditions checked:
 @platforms//cpu:x86_64
 @platforms//cpu:arm64

To see a condition's definition, run: bazel query --output=build <condition label>.

This instance of @distroless_base_nonroot//:distroless_base_nonroot has configuration identifier 9b656b9. To inspect its configuration, run: bazel config 9b656b9.

For more help, see https://bazel.build/docs/configurable-attributes#faq-select-choose-condition.

There the "distroless_base_nonroot" repository comes from oci_pull.

@Wyverald
Copy link
Member

Wyverald commented Mar 9, 2023

@bazel-io fork 6.2.0

ShreeM01 pushed a commit to ShreeM01/bazel that referenced this issue Mar 11, 2023
…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
keertk added a commit that referenced this issue Mar 20, 2023
…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]>
fweikert pushed a commit to fweikert/bazel that referenced this issue May 25, 2023
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug
Projects
None yet
Development

No branches or pull requests

4 participants