Skip to content

bazel info --host_platform=@my-mod//:host_platform fails on bazel 9.x with local path override #28954

@gzm0

Description

@gzm0

Description of the bug:

When upgrading to bazel 9:

$ bazel info --host_platform=@mod1//:host_platform
ERROR: com.google.devtools.build.lib.packages.BuildFileNotFoundException: no such package '@@mod1//': The repository '@@mod1' could not be resolved: Repository '@@mod1' is not defined

However:

$ bazel build --host_platform=@mod1//:host_platform
WARNING: Usage: bazel build <options> <targets>.
Invoke `bazel help build` for full description of usage and options.
Your request is correct, but requested an empty set of targets. Nothing will be built.
INFO: Found 0 targets...
INFO: Elapsed time: 0.123s, Critical Path: 0.01s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

(so the --host_platform setting is correct).

Which category does this issue belong to?

External Dependency

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Two modules are required:

# mod1/MODULE.bazel
module(name = "mod1")
# mod1/BUILD.bazel
platform(
    name = "host_platform",
    constraint_values = [],
    visibility = ["//visibility:public"],
)
# mod2/MODULE.bazel
bazel_dep(name = "mod1", version = "0.0.0")

local_path_override(
    module_name = "mod1",
    path = "../mod1",
)

Then run bazel info --host_platform=@mod1//:host_platform in mod2:

mod2$ bazel info --host_platform=@mod1//:host_platform
ERROR: com.google.devtools.build.lib.packages.BuildFileNotFoundException: no such package '@@mod1//': The repository '@@mod1' could not be resolved: Repository '@@mod1' is not defined

Expected behavior: The command shows bazel info (that's the behavior of bazel 8.5.0).

Notes:

  • build accepts the platform (bazel build --host_platform=@mod1//:host_platform)
  • Running adding bazel_dep(name = "platforms", version = "1.0.0") and running bazel info --host_platform=@platforms//host succeeds (so the local_path_override is likely the culprit).
  • Adding an alias to mod2 to also fixes the issue (run bazel info --host_platform=//:host_platform):
    # mod2/BUILD.bazel
    alias(
      name = "host_platform",
      actual = "@mod1//:host_platform",
    )

Which operating system are you running Bazel on?

Linux tos 6.14.0-37-generic #37~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 20 10:25:38 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

What is the output of bazel info release?

release 9.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 HEAD ?


If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

bazelisk --bisect=8.5.0..9.0.0 info --host_platform=@mod1//:host_platform

leads to:

632540d

Note: that bazel info --host_platform=@mod1//:host_platform --noincompatible_target_cpu_from_platform also seems to fail on bazel 9.0.0

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

Workaround

Define a module-local alias for the platform:

alias(
  name = "host_platform",
  actual = "@mod1//:host_platform",
)

The use --host_platform=//:host_platform instead of --@mod1//:host_platform.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2We'll consider working on this in future. (Assignee optional)help wantedSomeone outside the Bazel team could own thisteam-ExternalDepsExternal dependency handling, remote repositiories, WORKSPACE file.type: bug

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions