python rules can incorrectly alter the labels they receive

[dws]

🐞 bug report

Affected Rule

I've noticed this with the data attribute on py_library. I have not looked elsewhere.

Is this a regression?

I'm not sure if it's a regression. I noticed then problem when trying to transform labels in py_library rules in external repos to drop the name of the main repo, and instead rely on @@// to refer to the main repo, as is suggested in https://blog.engflow.com/2025/04/17/migrating-to-bazel-modules-aka-bzlmod---repo-names-againhellip/#removing-internal-references-to-the-repos-own-name as part of getting ready for bzlmod.

Description

Labels that begin with @ but which do not mention the main repo by name get turned into labels beginning with //. This happens even in external repos where the leading @ or @@ is supposed to refer to a label in the main repository.

🔬 Minimal Reproduction

Create a repo whose top-level BUILD.bazel file is:

load("@rules_python//python:defs.bzl", "py_library")

py_library(
    name = "test",
    data = ["@@//tools:data"],
)

then bazel query --output=build //:test and you'll see that the label inside data has been transformed to

data = ["//tools:data"]

while this may be benign if the py_library rule is in your main repo, it is NOT benign if the py_library is in an external repo, and you need the @@ there in order to force a reference into the main repo.

🔥 Exception or Error

The error when this happens in an external repo is due to the rule referring to labels that are not present in the external repo.

🌍 Your Environment

Operating System:

  
Ubuntu 24.04.2 LTS
  

Output of bazel version:

  
Build label: 8.2.1
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Thu Apr 17 18:22:55 2025 (1744914175)
Build timestamp: 1744914175
Build timestamp as int: 1744914175
  

Rules_python version:

  
1.5.0-rc0
  

Anything else relevant?

[rickeylev]

The rules don't modify their inputs in this way (they couldn't reliably, because select() expressions are opaque). What you're seeing is a behavior intrinsic to bazel.

[dws]

Yes, you're correct. I was fooled by the output of bazel query because I had not supplied the --consistent_labels flag.
I had not previously known that you had to opt-in to getting labels that make sense in bazel query output.