Loading top-level targets in local_path_override modules in child directory breaks the build

[mbland]

Description of the bug:

Using a Bazel module within a child directory (i.e., in the same repository, via local_path_override()) that calls load() on a top-level target breaks the build. The equivalent build using local_repository() in a WORKSPACE file succeeds.

In my mbland/bzlmod-local-module-bug example repo:

$ bazel build --nobuild --enable_bzlmod=false //...

INFO: Analyzed 0 targets (1 packages loaded, 0 targets configured).
INFO: Found 0 targets...
INFO: Elapsed time: 0.099s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

$ bazel build --nobuild --enable_bzlmod=true //...

WARNING: Target pattern parsing failed.
ERROR: Skipping '//...': error loading package under directory '': error loading package 'third_party/vendored_module': cannot load '//:top_level_target.bzl': no such file
ERROR: error loading package under directory '': error loading package 'third_party/vendored_module': cannot load '//:top_level_target.bzl': no such file
INFO: Elapsed time: 0.054s
INFO: 0 processes.
ERROR: Build did NOT complete successfully

local_path_override() and the bzmlod mechanism seem to assume the module will not reside within the same repo. The WORKSPACE or MODULE.bazel repository boundary marker files don't appear to have an effect.

Please see the README.md in my example repo for more information.

Which category does this issue belong to?

Core

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

git clone https://github.com/mbland/bzlmod-local-module-bug.git
cd bzlmod-local-module-bug
bazel build --nobuild --enable_bzlmod=true //...

Which operating system are you running Bazel on?

macOS 14.4.1 (23E224)

What is the output of bazel info release?

release 8.0.0-pre.20240415.1

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 ?

git@github.com:mbland/bzlmod-local-module-bug.git
31f1f966f4f2f1ef1c27cfe8ddf77a102fccdfa0

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

No. This happens in the current 7.1.1 release, as well as 7.0.0, 6.5.0, and 6.0.0.

Have you found anything relevant by searching the web?

No. All local_path_override() examples and issues I found presume the local module is outside the current directory.

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

No response

[fmeum]

Is this fixed by adding third_party to .bazelignore? It looks like Bazel recurses into the submodule.

[mbland]

It does seem to fix my example repo; I'll have to try it in my actual project later to confirm.

But if .bazelignore wasn't necessary for the WORKSPACE version to work, should that advice become part of the bzlmod migration "Introduce local repositories" advice? (Specifically for local_path_override() instances within the same directory/repo.)

[fmeum]

We should probably just fix this and align the behavior with that of your WORKSPACE example.

[Wyverald]

I think this is because we have some special handling to check if there's a WORKSPACE local_repository defined for a directory in the main repo. No such logic exists for the Bzlmod equivalent, hence the failure.

This is related to #21515. (or maybe even just a dupe)

[mbland]

Can confirm the .bazelignore workaround works for my main project.