System requirements violation (macOS version) when resolving pypi dependencies

[uwu-420]

Checks

• [x] I have checked that this issue has not already been reported.

• [x] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

• Create a project with this pyproject.toml

[project]
name = "pixi-test"
requires-python = ">=3.13"
version = "0.1.0"
dependencies = ["numpy>=2.2.3,<3"]

[tool.pixi.project]
channels = ["conda-forge"]
platforms = ["osx-64", "osx-arm64"]

[tool.pixi.feature.osx-64]
platforms = ["osx-64"]
system-requirements = {macos = "10.14"}

[tool.pixi.feature.osx-arm64]
platforms = ["osx-arm64"]
system-requirements = {macos = "14.0"}

[tool.pixi.environments]
osx-64 = {features = ["osx-64"], solve-group = "default"}
osx-arm64 = {features = ["osx-arm64"], solve-group = "default"}

• Run pixi install
• The resulting (simplified) lockfile looks like this

version: 6
environments:
  default:
    channels:
    - url: https://conda.anaconda.org/conda-forge/
    indexes:
    - https://pypi.org/simple
    packages:
      osx-64:
      # ...
      - pypi: https://[...]/numpy-2.2.3-cp313-cp313-macosx_10_13_x86_64.whl
      osx-arm64:
      # ...
      - pypi: https://[...]/numpy-2.2.3-cp313-cp313-macosx_11_0_arm64.whl
  osx-64:
    channels:
    - url: https://conda.anaconda.org/conda-forge/
    indexes:
    - https://pypi.org/simple
    packages:
      osx-64:
      # ...
      - pypi: https://[...]/numpy-2.2.3-cp313-cp313-macosx_14_0_x86_64.whl
  osx-arm64:
    channels:
    - url: https://conda.anaconda.org/conda-forge/
    indexes:
    - https://pypi.org/simple
    packages:
      osx-arm64:
      # ...
      - pypi: https://[...]/numpy-2.2.3-cp313-cp313-macosx_14_0_arm64.whl
packages:
# ...

Issue description

My goal was to specify different macos system-requirements for osx-64 and osx-arm64 because currently it's impossible to set it to macOS 10.14 because that does not exist for osx-arm64.

IIUC a workaround would be what I tried in this pyproject.toml, i.e. creating separate environments for osx-64 and osx-arm64 and setting the macos in their corresponding system-requirements.

But doing that revealed some bogus behavior when resolving pypi-dependencies. Here I chose numpy, because it offers wheels for different macOS versions. For the osx-64 environment I want to support macOS 10.14+ but the resolver picks a wheel for this environment that requires macOS 14.0+ which violates this requirement.

Expected behavior

For the osx-64 environment the resolver should have chosen numpy-2.2.3-cp313-cp313-macosx_10_13_x86_64.whl instead of numpy-2.2.3-cp313-cp313-macosx_14_0_x86_64.whl.

[tdejager]

Thanks for the report, that definitely looks like a bug to me!

[tdejager]

I guess we might also need an issue to the system-requirement for osx-arm64 and osx-64 seperately. wdyt @ruben-arts?

[ruben-arts]

@tdejager do you mean this issue?: https://github.com/prefix-dev/pixi/issues/2714

[uwu-420]

I have another example that probably fits this issue

[project]
name = "pixi-test"
requires-python = ">=3.13,<3.14"
version = "0.1.0"
dependencies = []

[tool.pixi.project]
channels = ["conda-forge"]
platforms = ["osx-arm64", "linux-64"]

[tool.pixi.pypi-dependencies]
numpy = ">=2.2.3,<3"

[tool.pixi.system-requirements]
macos = "14.0"

[tool.pixi.feature.foo.system-requirements]
macos = "11.0"

[tool.pixi.environments]
foo = { features = ["foo"] }

where we get a violating numpy wheel for the foo environment. I think the macos = "11.0" line isn't really considered at all by pixi. I can give it any garbage value and nothing will complain. If it is intentional that a system requirement set by a feature is ignored when there's already something in the general system requirements then I'd say a warning that it's ignored would be good for the UX.

[cmalinmayor]

Additional Example: pyscipopt build failure due to incorrect platform tag (Apologies for the LLM assist making this comment, I'm a bit out of my depth when it comes to the ins and outs of this and I wanted to test it thoroughly - please feel free to ask clarifications if needed)

Environment

• OS: macOS 14.1 (arm64)
• Pixi version: 0.59.0
• Python: 3.11/3.14 (in pixi environment)

Problem When pixi resolves pyscipopt (either directly or transitively), it attempts to build from source with platform tag macosx-11.0-arm64 instead of selecting the available macosx_14_0-arm64 wheels from PyPI. This causes build failures because SCIP headers are not available.

Minimal Reproducible Example

  pyproject.toml:
  [project]
  name = "pixi-pyscipopt-test"
  version = "0.1.0"
  requires-python = ">=3.11"
  dependencies = [
    "pyscipopt>=5.6.0",
  ]

  [tool.pixi.workspace]
  channels = ["conda-forge"]
  platforms = ["osx-arm64"]

  [tool.pixi.dependencies]
  pip = "*"

Error: Failed to build pyscipopt==5.6.0 fatal error: 'scip/type_retcode.h' file not found

Regular pip correctly selects the wheel:

  python3 -m venv test-venv
  source test-venv/bin/activate
  pip install pyscipopt==5.6.0

Key Observations

1. PyPI has wheels for macosx_14_0_arm64 (cp38-cp313): https://pypi.org/project/pyscipopt/5.6.0/#files
2. Pixi's build output shows: build/lib.macosx-11.0-arm64-cpython-314
3. This affects both direct and transitive dependencies

Related to funkelab/ilpy#83.