feat: Derive c_stdlib build variants from system requirements#6320
Open
hunger wants to merge 2 commits into
Open
feat: Derive c_stdlib build variants from system requirements#6320hunger wants to merge 2 commits into
c_stdlib build variants from system requirements#6320hunger wants to merge 2 commits into
Conversation
Inject conda-forge c_stdlib/c_stdlib_version build variants from a platform's declared virtual packages (__osx, __glibc) in Workspace::variants(), so build backends pin the minimum OS/libc target and stop emitting wheels tagged for the host OS version (e.g. macosx_26_0). Explicit [workspace.build-variants] entries still win; derivation only fills absent keys. osx-* derives macosx_deployment_target, linux-* derives sysroot; windows and unmatched platforms are skipped. musl and __cuda are left for a follow-up (TODO marker). Refs: prefix-dev#6175
…ersion
rattler-build hard-codes MACOSX_DEPLOYMENT_TARGET (11.0/10.9) and ignores
the c_stdlib_version variant, so maturin/PEP 517 wheels are tagged for the
host SDK (e.g. macosx_26_0). For compiled (non-noarch) macOS builds the
python backend now injects a build-script env entry
MACOSX_DEPLOYMENT_TARGET = ${{ c_stdlib_version }}, rendered lazily by
rattler-build from the variant pixi derives off the platform's __osx
system requirement. An explicit value in the backend config wins.
Adds a cross-platform integration test (system-requirements-osx-python
fixture) asserting a non-noarch package builds, plus the deployment-target
value on macOS.
Refs: prefix-dev#6175
Contributor
|
Nope thats wrong. Its handled by the macosx_deployment_target package. |
baszalmstra
reviewed
Jun 9, 2026
Comment on lines
+42
to
+68
| /// Build-script env entry pinning the macOS deployment target for compiled | ||
| /// (non-noarch) macOS builds (pixi issue #6175). | ||
| /// | ||
| /// rattler-build hard-codes `MACOSX_DEPLOYMENT_TARGET` (11.0/10.9) and ignores | ||
| /// the `c_stdlib_version` variant, so maturin/PEP 517 wheels get the host SDK | ||
| /// tag. We override it with `${{ c_stdlib_version }}` (rendered lazily by | ||
| /// rattler-build), which pixi derives from the platform's `__osx` requirement. | ||
| /// `None` off macOS, for noarch, or when the variant is absent. | ||
| fn macos_deployment_target_env( | ||
| host_platform: Platform, | ||
| variants: &HashSet<NormalizedKey>, | ||
| is_noarch: bool, | ||
| ) -> Option<(String, Value<String>)> { | ||
| if is_noarch | ||
| || !host_platform.is_osx() | ||
| || !variants.contains(&NormalizedKey::from("c_stdlib_version".to_string())) | ||
| { | ||
| return None; | ||
| } | ||
|
|
||
| let template = | ||
| JinjaTemplate::new("${{ c_stdlib_version }}".to_string()).expect("valid jinja template"); | ||
| Some(( | ||
| "MACOSX_DEPLOYMENT_TARGET".to_string(), | ||
| Value::new_template(template, None), | ||
| )) | ||
| } |
Contributor
There was a problem hiding this comment.
This is not needed because this is done by the action script of the macos_deployment_target package.
baszalmstra
reviewed
Jun 9, 2026
Comment on lines
+32
to
+38
| let (vp_name, provider) = if subdir.is_osx() { | ||
| ("__osx", "macosx_deployment_target") | ||
| } else if subdir.is_linux() { | ||
| ("__glibc", "sysroot") | ||
| } else { | ||
| return Vec::new(); | ||
| }; |
Contributor
There was a problem hiding this comment.
Note that these are only valid when building against conda-forge. I think we should gate that.
baszalmstra
reviewed
Jun 9, 2026
Comment on lines
+7
to
+10
| /// conda-forge variant key naming the C stdlib provider for a build. | ||
| const C_STDLIB: &str = "c_stdlib"; | ||
| /// conda-forge variant key carrying the minimum C stdlib version. | ||
| const C_STDLIB_VERSION: &str = "c_stdlib_version"; |
Contributor
There was a problem hiding this comment.
The variant key name is not conda-forge specific. Only to what it maps.
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
2 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.
Derive
c_stdlibbuild variants from system requirementsProblem
When pixi-build builds a compiled (non-noarch) package, the C stdlib target is
selected through conda-forge's
c_stdlib/c_stdlib_versionbuild variants(consumed by the
stdlib('c')recipe function). Today users have to spell thoseout by hand in
[workspace.build-variants], even though pixi already knows thetarget from the workspace's
platforms.Changes
Derive the variant pair from system requirements (
pixi_core)Workspace::variantsnow derivesc_stdlib/c_stdlib_versionfrom theplatform's declared virtual packages and fills them in only where the user
hasn't set them explicitly (an explicit
[workspace.build-variants]entryalways wins):
c_stdlibc_stdlib_versionosx-*__osxmacosx_deployment_target__osxversionlinux-*__glibcsysroot__glibcversionWindows is skipped (no meaningful stdlib version), and a platform with no
matching virtual package derives nothing rather than inventing a value. The
logic lives in the new
crates/pixi_core/src/workspace/stdlib_variants.rs.__musland__cudaare noted as follow-ups (TODO(#6175)). They are not fully describedin any CEP, so whatever we do there is goiung to be incomplete.
Set
MACOSX_DEPLOYMENT_TARGETon macOS (pixi_build_python)For compiled macOS builds where the
c_stdlib_versionvariant is present, thepython backend injects
MACOSX_DEPLOYMENT_TARGET=${{ c_stdlib_version }}intothe build-script env (rendered lazily by rattler-build). It's skipped for noarch
builds, off macOS, and when the variant is absent. An explicit
MACOSX_DEPLOYMENT_TARGETin the backend config is left untouched — the derivedvalue only fills the gap.
Tests
derive_stdlib_variants(osx, linux, windows-skipped,glibc-absent, and bare-subdir defaults).
unset key is still filled in.
macos_deployment_target_envand two end-to-endgenerate_recipetests (derived value wired in; user config respected).test_macos_deployment_target_from_system_requirementsplus fixture
tests/data/pixi-build/system-requirements-osx-pythonpinningmacos = "12.0"(deliberately different from the 13.0 osx-subdir default).It asserts a single compiled artifact is produced on every platform, and on
macOS that the build script env carries
MACOSX_DEPLOYMENT_TARGET=12.0.Fixes #6175.
AI Disclosure
Tools: Claude
Checklist:
schema/model.py.