feat(uv): parameterize the platform parent in gazelle_python_manifest

[sallustfire]

AI written, human reviewed.

Fixes #1416.

Per venv, gazelle_python_manifest declares a throwaway platform() whose flags force --@<hub>//dep_group=<venv>, then pushes the hub's gazelle_index_whls filegroup through platform_transition_filegroup. That synthetic platform hardcodes parents = ["@platforms//host"], and the transition replaces --platforms wholesale, so everything that has to build under the transitioned configuration resolves toolchains against a bare os+cpu platform. Two real setups break:

1. Custom --host_platform / hermetic toolchains. With common --host_platform=@host_platform//:platform (a platform carrying libc/kernel/etc. constraints that hermetic cc toolchains gate on) and --repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1, PEP 517 sdist builds in the hub (python-ldap, PyMuPDF, ...) fail analysis under the transition in our build:

   ERROR: While resolving toolchains for target
   @@aspect_rules_py++uv+sdist_build__diskover__python_ldap__3_4_5//:whl:
   No matching toolchains found for types:
     @@bazel_tools//tools/cpp:toolchain_type
   

Those sdists are the packages the manifest exists to index (python-ldap imports as ldap/ldapurl/ldif, PyMuPDF as fitz), so filtering them out isn't an option.

2. Cross-compilation ([Bug]: gazelle_python_manifest hard-codes @platforms//host, breaks cross-platform builds #1416). Building with --platforms=<linux target> from a darwin host, the transition pulls wheel selection back to the darwin host platform and fails with No matching toolchains found for types: @@aspect_rules_py+//py/private/toolchain:native_build_toolchain_type.

The fix

A platform_parents parameter, threaded into the synthetic platform's parents. The default preserves current behavior exactly.

• The list must hold exactly one label, since platform() accepts at most one parent, and the macro fails eagerly at load time with a message naming the parameter otherwise. That also rejects the empty list, whose constraint-free platform would quietly degrade wheel selection to sdist fallbacks. The list shape mirrors the native parents attribute so callers can lift a parents list off an existing platform() unchanged.
• The default is built as Label("@platforms//host") in the defining module, so consumers need no direct bazel_dep on platforms to use it. Previously the hardcoded string resolved against the caller's repo mapping.

Why parameterization and not something smarter

• The platform-with-flags mechanism can't become a plain Starlark transition. A transition setting --@<hub>//dep_group would have to statically declare that flag label as a transition output, but the hub name is a macro parameter, unknown at rule-definition time. platform(flags = ...) is data, constructible per hub at load time.
• platform() parents must be a static label; there's no "inherit the incoming platform". Deriving the parent from the incoming --platforms isn't implementable from a macro, and it would make the checked-in manifest depend on whatever --platforms a developer happened to pass. The explicit parameter keeps bazel run :gazelle_python_manifest.update reproducible, and covers the case where the desired parent is a target platform rather than the current one.

Test coverage

New snapshot case e2e/cases/gazelle-platform-parents-1416: builds a manifest over the existing pypi_uv_deps_650 hub's extras venv with a caller-supplied parent carrying a case-local constraint, and pins two goldens, the manifest YAML (built end-to-end) and a probe genrule whose select() keys on that constraint, transitioned through the macro-generated synthetic platform. If the macro ever ignores platform_parents, the probe golden flips from custom-parent to default-parent and the diff test fails (verified by reverting the fix).

---

• Changes are visible to end-users: yes
• Searched for relevant documentation and updated as needed: yes (docs/uv.md Gazelle section)
• Breaking change (forces users to change their own code or config): no
• Suggested release notes appear below: yes

gazelle_python_manifest now accepts platform_parents, letting the manifest's per-venv wheel selection parent onto a custom platform. Needed for repos with a custom --host_platform (hermetic C++ toolchains) and for cross-compilation.

Test plan

• New e2e snapshot case as described above; bazel run //:snapshots plus all 36 snapshot diff tests pass.
• bazel build //gazelle-platform-parents-1416:all and the unmodified //uv-gazelle-778:gazelle_python_manifest (default-parent path through the new Label() substitution) both build.
• Verified on macOS (darwin_arm64, Bazel 8.6.0) in addition to Linux: bazel run //:snapshots reproduces both goldens byte-identically, and bazel query --output=build shows the synthetic platform's parents is the custom platform in the new case and @platforms//host for existing callers.
• bazel test //uv/private/gazelle_manifest/tests:test passes; buildifier clean on the changed files.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 25e4d698-98a4-4e20-9aec-3031952237cb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[xangcastle]

Thanks for doing this @sallustfire this will be landed on #1470 while I am keeping your authoring.
@jbedard this is a change in the public API