feat(uv): parameterize the platform parent in gazelle_python_manifest - #1470
Merged
Merged
Conversation
The per-venv synthetic platform gazelle_python_manifest generates hardcoded parents = ["@platforms//host"], and the dep_group transition replaces --platforms wholesale. Anything building under the transitioned configuration therefore resolved toolchains against a bare os+cpu platform, which breaks builds with a custom --host_platform (hermetic cc toolchains gating on extra constraints fail sdist builds in the hub at analysis) and cross-compilation (wheel selection snaps back to the host platform, issue #1416). Add a platform_parents parameter, defaulting to the current behavior so existing callers are unaffected, and thread it into the synthetic platform's parents. The list must hold exactly one label (platform() accepts at most one parent); the macro fails eagerly with a message naming the parameter otherwise. The default is built as Label("@platforms//host") in the defining module, so callers need no direct bazel_dep on platforms to use it. A new e2e snapshot case builds a manifest under a caller-supplied parent and pins a probe transitioned through the macro-generated platform, selecting on a constraint only the custom parent carries. Fixes #1416 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
✨ Aspect Workflows Tasks📅 Thu Aug 20 03:08:38 UTC 2026 ✅ 44 successful tasks
⏱ Last updated Thu Aug 20 03:16:02 UTC 2026 · 📊 GitHub API quota 2,524/15,000 (17% used, resets in 10m) |
xangcastle
force-pushed
the
xangcastle/gazelle_platform_parents
branch
from
August 20, 2026 03:02
3a7a7fb to
58cf020
Compare
Moves generate.py and update.sh out of the package that holds the public defs.bzl into //uv/private/gazelle_manifest/tools with its own BUILD, and switches the _generator implicit attribute and the update label to absolute labels. Implicit-attribute visibility is checked against the .bzl's package, so the generator stays private to //uv/private/gazelle_manifest.
…abel Replaces the platform_parents single-element-list parameter (not yet released) with a singular platform_parent label before the API ships. A list that fails on any length other than one promises plurality the underlying platform() rule does not support. The load-time check now rejects any non-string, non-Label value (lists, selects) with a message naming the parameter, instead of dying inside len() or native.platform. Also documents the cross-compilation trade-off: with platform_parent set to a target platform, <name>.update builds sdist fallbacks for that platform, which needs a capable execution platform (e.g. RBE) unless everything resolves to wheels.
Strengthens the gazelle-platform-parents-1416 case to cover the behavior issue #1416 actually reported — wheel selection following the caller's platform — not just constraint inheritance: - parent_platform is now a fully-specified linux_x86_64 platform carrying the platform_libc/platform_version flags, making the case the real cross-compilation scenario and host-invariant. The flags ride on the platform because their defaults are host-detected: without them manylinux config_settings never match off-linux and native packages silently degrade to sdist fallbacks. - A new analysis-time probe snapshots which wheel variant each hub dependency resolves to under the macro-generated platform (distribution: platform-class lines, no versions or tag spellings, so lock bumps don't churn the golden). Native packages pin to linux_x86_64, pure ones to any, and any sdist fallback shows up explicitly. Verified by simulating the regression: the golden flips to macosx wheels on a darwin host. - The manifest YAML golden is replaced by a build_test: the YAML content is platform-independent, so the golden only re-pinned another case's hub state; building the manifest end-to-end from the linux-selected wheels is the actual signal.
xangcastle
force-pushed
the
xangcastle/gazelle_platform_parents
branch
from
August 20, 2026 03:07
58cf020 to
201d27a
Compare
4 tasks
py_binary startup benchmark
sys.path quality
Bazel analysis benchmark
py_image_layer benchmark
|
xangcastle
marked this pull request as ready for review
August 20, 2026 03:20
Member
Author
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Member
Author
|
Codex Review: Didn't find any major issues. Chef's kiss. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
jbedard
reviewed
Aug 20, 2026
jbedard
approved these changes
Aug 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1416. Supersedes #1468, carrying @sallustfire's commit unchanged (cherry-picked, authorship preserved) plus three follow-up commits.
Base change (from #1468, by @sallustfire)
gazelle_python_manifest's synthetic per-venv platforms hardcodedparents = ["@platforms//host"], so theplatform_transition_filegroupover the hub's wheel index replaced the caller's--platformswholesale. That broke custom--host_platformsetups (hermetic cc toolchains) and cross-compilation. The fix parameterizes the parent platform; the default preserves current behavior and is resolved as aLabelin rules_py's own repository, so consumers need nobazel_deponplatforms.Follow-up commits
platform_parentis a single label, not a list. The list form failed at load time on any length other than one — promising plurality the underlyingplatform()rule does not support. Renamed and made singular before the API ships. The load-time check now rejects any non-string, non-Label value (lists, selects) with a message naming the parameter.Wheel selection is pinned under a real cross-compilation parent. The e2e case's parent is now a fully-specified
linux_x86_64platform carrying theplatform_libc/platform_versionflags — issue #1416's actual scenario, and host-invariant. The flags ride on the platform because their defaults are host-detected: without them, manylinuxconfig_settings never match off-linux and native packages silently degrade to sdist fallbacks (the other half of the config chimera the issue describes; this is also the documented recipe for real cross-compilation parents). A new analysis-time probe snapshots which wheel variant each hub dependency resolves to (distribution: platform-classlines — no versions or tag spellings, so lock bumps don't churn the golden). Native packages pin tolinux_x86_64, pure ones toany, and sdist fallbacks surface explicitly. The manifest YAML golden is replaced by abuild_test: the YAML content is platform-independent, so it only re-pinned another case's hub state; building the manifest end-to-end from linux-selected wheels is the actual signal.Gazelle manifest tooling moved to a
tools/subpackage.generate.pyandupdate.shmove out of the package holding the publicdefs.bzlinto//uv/private/gazelle_manifest/toolswith absolute labels; implicit-attribute visibility is checked against the defining.bzl's package, so:generatorstays private.Test plan
manifest_build_test); goldens regenerated viabazel run //:snapshotson darwin_arm64 — the wheel-selection golden showslinux_x86_64wheels selected from a mac host.platform_parent): the constraint probe flips todefault-parentand the wheel probe flips tomacosx_*wheels.//uv/private/gazelle_manifest/tests:testpasses; buildifier clean on changed files.docs/uv.mdGazelle section)gazelle_python_manifestnow acceptsplatform_parent, 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; in the cross-compilation case, carry theplatform_libc/platform_versionflags on the parent platform.🤖 Generated with Claude Code