refactor(wheels): propagate wheels via PyWheelInfo instead of DefaultInfo

[jbedard]

This was a robots work to "stop propagating all the wheels via DefaultInfo" which @dzbarsky mentioned on slack.

--

Previously, wheel files leaked into DefaultInfo.files of every target that transitively depended on a pip package. This happened because whl_requirements used whl_mode_transition to flip lib_mode=whl across the dep graph, causing install aliases to resolve to whl_lib (a py_library with the raw .whl file as srcs). Since py_library propagates DefaultInfo.files transitively, every intermediate target accumulated all transitive .whl files as visible build outputs.

The fix introduces PyWheelInfo, a dedicated provider that carries wheel files without putting them in DefaultInfo:

• whl_install now returns PyWheelInfo(files=depset([archive])) alongside its existing DefaultInfo and PyInfo
• py_library propagates PyWheelInfo transitively from its deps, so the full set of transitive wheels is reachable from any node in the dep graph
• whl_requirements reads PyWheelInfo.files directly, with no cfg transition

Because whl_requirements no longer needs whl_mode_transition to surface wheels, the entire lib_mode machinery becomes unnecessary:

• whl_mode_transition was only used by whl_requirements (now gone) and py_whl_library (which only existed to force whl mode)
• lib_mode_transition on pep517_whl existed solely to counteract whl_mode_transition in source-build dep chains; without whl_mode_transition there is nothing to counteract
• whl_lib in each package repo and the libs_are_whls arm of the install select are removed; install always resolves to actual_install
• py_whl_library in the hub becomes a plain alias; PyWheelInfo is available on the same target without any mode transition

libs_are_libs and libs_are_whls config_settings are retained as no-op stubs for API compatibility.

---

Changes are visible to end-users: yes/no

• Searched for relevant documentation and updated as needed: yes/no
• Breaking change (forces users to change their own code or config): yes/no
• Suggested release notes appear below: yes/no

Test plan

• Covered by existing test cases
• New test cases added
• Manual testing; please provide instructions so we can reproduce:

[jbedard]

My questions...

After #907 does this still have an effect?

....

PR #907 is complementary but addresses a different artifact: it removes install_dir (the unpacked wheel directory) from whl_install's DefaultInfo.files. Our change removes raw .whl files from DefaultInfo by eliminating whl_lib.

However, PR #907 alone doesn't fully solve either problem. install_dir was removed from whl_install's own DefaultInfo.files, but py_library still propagated it further — because py_library.DefaultInfo.files included transitive =
[transitive_srcs], where transitive_srcs collected PyInfo.transitive_sources from all deps (which includes install_dir). That's the separate change already on this branch that drops the transitive from py_library's DefaultInfo.

So after PR #907 merges, our change still has positive effects:

1. Removes whl_lib — the only remaining source of raw .whl files in DefaultInfo.files, which PR fix(whl_install): remove install_dir from DefaultInfo.files #907 doesn't touch
2. Removes the transition machinery — whl_mode_transition, lib_mode_transition, py_whl_library — none of which PR fix(whl_install): remove install_dir from DefaultInfo.files #907 touches
3. Fixes whl_requirements for transitive collection — with py_library no longer propagating transitive files through DefaultInfo, the old s.files-based whl_requirements would silently collect nothing from SCC py_library targets;
   PyWheelInfo is what makes transitive collection correct

The two changes together clean up both sides: PR #907 removes install dirs, our change removes wheel archives and the mode-switching machinery that existed to surface them.

[aspect-workflows]

Bazel 8 (Test)

All tests were cache hits

111 tests (100.0%) were fully cached saving 56s.

---

Bazel 9 (Test)

All tests were cache hits

111 tests (100.0%) were fully cached saving 1m.

---

Bazel 8 (Test)

e2e

All tests were cache hits

51 tests (100.0%) were fully cached saving 42s.

---

Bazel 9 (Test)

e2e

All tests were cache hits

51 tests (100.0%) were fully cached saving 1m 8s.

---

Bazel 8 (Test)

examples/uv_pip_compile

All tests were cache hits

1 test (100.0%) was fully cached saving 444ms.

[jbedard]

Me talking to robots...

why was PyWheelInfo not used here previously?

⏺ PyWheelInfo was defined but never wired up to actually carry wheel files through the graph. The original design used a different mechanism entirely:

1. whl_requirements applied cfg = whl_mode_transition to its srcs, which flipped lib_mode to "whl"
2. That transition caused the install alias in each package hub to resolve to whl_lib (a py_library(srcs=[":whl"])) instead of the normal installed library
3. whl_requirements then just read s.files (i.e., DefaultInfo.files) from those transitioned targets — the raw .whl was sitting there because whl_lib put it in DefaultInfo.files via srcs

So there was no need for a provider — the mode transition was doing the selection work, and DefaultInfo was the transport. PyWheelInfo was defined in providers.bzl but nobody ever set it with wheel files, so it was dead code.

Our change inverts this: whl_install now populates PyWheelInfo.files with the archive, py_library propagates it transitively, and whl_requirements reads it directly — no transition needed.