[7.0 regression] Unable to load workspace "@myworkspace" where new_local_repository.build_file refers to BUILD file w/ label "@myworkspace//path/to:BUILD.bazel"

[ghost]

Description of the bug:

Bazel 7.0.0rc2 fails to load my project's main workspace, where I have a new_local_repository whose build_file argument contains a fully qualified label inside the workspace itself. The build_file label is fully qualified because it appears in a macro which is shared among multiple repositories.

Which category does this issue belong to?

Loading API

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

Please see repro repo at https://github.com/beasleyr-vmw/repro-bazel7-new_local_repository .

The main repository is named "canon", and I try to instantiate a new_local_repository with build_file = "@canon//:BUILD.shared.bazel".

$ USE_BAZEL_VERSION=7.0.0rc2 bazelisk build :dummy
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
ERROR: .../b7-new_local_repository_cannot_refer_to_self/WORKSPACE.bazel:5:12: fetching new_local_repository rule //external:shared: Unable to load package for @canon//:BUILD.shared.bazel: not found.
ERROR: no such package '@shared//': Unable to load package for @canon//:BUILD.shared.bazel: not found.
ERROR: .../b7-new_local_repository_cannot_refer_to_self/BUILD.bazel:1:8: //:dummy depends on @shared//:dummy in repository @shared which failed to fetch. no such package '@shared//': Unable to load package for @canon//:BUILD.shared.bazel: not found.
ERROR: Analysis of target '//:dummy' failed; build aborted: Analysis failed
INFO: Elapsed time: 5.126s, Critical Path: 0.02s
INFO: 1 process: 1 internal.
ERROR: Build did NOT complete successfully

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

release 7.0.0rc2

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

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

Yes.

$ git rev-parse release-7.0.0rc2
2cb3159aed5b73eb13a866d8fe63953d388cd30b

bazelisk --bisect 7.0.0-pre.20230917.3..2cb3159aed points to 9be1be9.

Have you found anything relevant by searching the web?

No response

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

See #1248 for other use cases of this feature.

[fmeum]

Cc @Wyverald

[Wyverald]

Thanks for the repro. This bug is specific to new_local_repository, since the build_file attribute is actually of type str rather than Label (see docs). This, in turn, seems to be in order to support a legacy use case where a path (instead of a label) could be used for this attribute (see code). This is otherwise fine, but in case a label is used, it's treated as a canonical label, forgoing repo mapping altogether (see code).

The proper fix would be to change the attribute type to a label, which is potentially backwards-incompatible but well, we are allowed to do that.

[Wyverald]

@bazel-io fork 7.0.0

[iancha1992]

A fix for this issue has been included in Bazel 7.0.0 RC5. Please test out the release candidate and report any issues as soon as possible. Thanks!

[ghost]

A fix for this issue has been included in Bazel 7.0.0 RC5. Please test out the release candidate and report any issues as soon as possible. Thanks!

Confirmed resolution w/ RC5. Thanks!

[andrewkatson]

I think this still happens with Mac. Should I open a new issue?

[fmeum]

Please do!

[andrewkatson]

Well I made an example but it actually succeeded so never mind :) https://github.com/andrewkatson/bazel_mac_new_local_repo