Label behaves differently between WORKSPACE and bzlmod build

[fmeum]

Description of the problem / feature request:

In some situations, the value of a string constant constructed via str(Label(...)) will be absolute without --experimental_enable_bzlmod, but relative with the flag enabled.

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

I haven't been able to produce a truly minimized reproducer, but at least have a fully reproducible one:

$ git clone -b label-issue https://github.com/fmeum/rules_go
$ bazelisk build //go/tools/releaser
...
DEBUG: /home/fhenneke/.cache/bazel/_bazel_fhenneke/da2ee2360ba14ac857bdb47dfbba9b7d/external/io_bazel_rules_go/go/private/nogo.bzl:18:10: @io_bazel_rules_go//:default_nogo
...
INFO: Build completed successfully, 1 total action
$ bazelisk build //go/tools/releaser --experimental_enable_bzlmod
DEBUG: /home/fhenneke/git/rules_go/go/private/nogo.bzl:18:10: //:default_nogo
ERROR: /home/fhenneke/git/rules_go/BUILD.bazel:73:16: in nogo attribute of go_context_data rule //:go_context_data: rule '@.go_dependencies.io_bazel_rules_nogo//:default_nogo' does not exist
ERROR: /home/fhenneke/git/rules_go/BUILD.bazel:73:16: Analysis of target '//:go_context_data' failed
ERROR: Analysis of target '//go/tools/releaser:releaser' failed; build aborted: 
...
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

The reproducer differs from rules_go upstream only in fmeum/rules_go@661366a.

Note that I added the str(Label(...)) construction in https://github.com/bazelbuild/rules_go/blob/979c3c634682c7bfda33bae44df4ea1c0ab2d624/go/private/nogo.bzl#L15 only recently in an effort to use repo-relative labels wherever possible. It did work with WORKSPACE builds, but I am now seeing it fail with bzlmod.

What operating system are you running Bazel on?

Linux

What's the output of bazel info release?

development version

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

Bazelisk's last_green

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

20d8807

I expect this to reproduce with 5.0.0, but haven't been able to verify since my reproducer triggers the bug fixed in 48a0fc5 first.

Have you found anything relevant by searching the web?

• Labels passed to module extensions don't survive until BUILD time #14580 (both deal with Labels emitted by repository rules)

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

[Wyverald]

I believe this is an unfortunate interaction between several factors in play:

• With Bzlmod disabled, if your workspace name is foo, then the label @foo//:bar is often a completely different target than @//:bar. This is because the main repo technically only ever has an empty repo mapping; the fact that @foo//:bar works at all is due to a hack where we implicitly introduce a local_repository(name="foo",path=".") clause.
• None of this happens with Bzlmod enabled; @foo//:bar simply goes through the repo mapping of the main repo and gets interpreted as @//:bar.
• However, when serializing label objects with str(myLabel), we special-case labels in the main repo to not output the @repo part (code:

  bazel/src/main/java/com/google/devtools/build/lib/cmdline/RepositoryName.java

  Lines 200 to 202 in e6bb6fc

  	public String getCanonicalForm() {
  	return isMain() ? "" : getNameWithAt();
  	}

  ). If you're thinking like me, this would look completely ridiculous, but I'm afraid to change the behavior because it might break thousands of users. So I just live with it :)

Hopefully this sheds some light on why you might run into the problem you noticed. As for how this should fixed, I have no idea :) One thing that could be done is to use Label objects directly instead of their serialized forms, but I realize that's not always possible.

[Wyverald]

With the recent fixes around repo mapping (especially #14852), the first bullet point above should be less of a problem (@foo//:bar is the same as @//:bar now even without Bzlmod). I'll go ahead and close this one but please feel free to reopen if the problem persists.