Including multiple versions of a wheel file with respect to macosx version

[uwu-420]

Problem description

(The same principle applies to the glibc version)

I'm on osx-arm64 with macOS 15.3
When I have the following in pyproject.toml

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

and then do pixi add --pypi numpy then I see in the pixi.lock file that pixi only adds the numpy-2.2.3-cp313-cp313-macosx_11_0_arm64.whl file although there is a numpy-2.2.3-cp313-cp313-macosx_14_0_arm64.whl file on PyPI. So the first one requires macOS 11.0+ and the second one macOS 14.0+ (due to using more modern Apple Accelerate framework features for the linear algebra stuff).

I guess your way of handling this makes sense. Still, just for comparison uv would include both versions in the lockfile. My problem with how pixi does this is that it then misses out on these wheels that require a higher macOS version but in return offer e.g. improved performance for the platforms where it's supported. But I still want to ensure that my project runs on macOS 11.0+

If only numpy is such a special case I wouldn't mind creating two separate environments, one which requires macOS 11.0+ and one that requires macOS 14.0+ but as soon as there are multiple packages that have multiple wheels for different macOS versions and they do not fit this environment schema we could miss out on "optimal" wheels for a platform again. Creating more and more fine-grained environments to cover all the possibilities would become a huge mess I think.

I know that pixi is already trying to resolve for the latest package versions but this is about trying to always pick the highest macOS/libc/whatever version that is compatible with the current platform when actually installing the packages. Or does that violate some assumption or design decision you made? I'd just like to bring attention to this and put it up for debate. Thanks for the great work on pixi so far :)

[ruben-arts]

Thanks for the write-up. Unfortunately, we are currently limited to one solution per environment. Which means it will pick the version that works for most machines instead of the most optimized one.

Setting a system-requirements field means that you tell the solver that it can expect that version of macos. Meaning, it doesn't get the wheel for a higher version.

We have currently focused on reproducibility (always install the same wheel) vs flexibility(always install the most fitting wheel), but I can see the requests for this flexible approach increasing.

I can't give any estimation or plan right now, but know we are aware of the issue and do hope to figure out a solution to this problem.