`--python-platform` can install source build for host instead of target

[NiklasRosenstein]

Summary

I'm building a ZIP for an AWS Lambda using uv pip install on a Mac, so I pass the --python-platform option. Since I didn't know which manylinux variant to pick exactly, I went with x86_64-manylinux2014. Here I discovered that Uv tries to use the latest Numpy version (2.3.3) but doesn't find a binary distribution and instead compiles it on the host, resulting in Darwin-binaries in what is supposed to be a Linux distribution of the project.

This can be reproduced with

$ uv pip install --no-config --exact --managed-python --target packages --python 3.12 --python-platform x86_64-manylinux2014 -- numpy
Using CPython 3.12.11 interpreter at: .venv/bin/python3
Resolved 1 package in 13ms
   Building numpy==2.3.3
⠋ Preparing packages... (0/1)                                                                                                                         

And once it's done you're left with no Linux binaries at all:

$ tree packages/ | grep linux
$ tree packages/ | grep darwin | head -n2
│   │   ├── _multiarray_tests.cpython-312-darwin.so
│   │   ├── _multiarray_umath.cpython-312-darwin.so

It can be fixed with using --only-binary numpy:

$ uv pip install --no-config --exact --managed-python --target test-build --python 3.12 --python-platform x86_64-manylinux2014 --only-binary numpy -- numpy
Using CPython 3.12.11 interpreter at: .venv/bin/python3
Resolved 1 package in 10ms
Uninstalled 1 package in 135ms
Installed 1 package in 16ms
 - numpy==2.3.3
 + numpy==2.2.6
$ tree test-build/ | grep linux | head -n2
│   │   ├── _multiarray_tests.cpython-312-x86_64-linux-gnu.so
│   │   ├── _multiarray_umath.cpython-312-x86_64-linux-gnu.so

It seems adding --no-build works as well (which would be preferable in my case since I would like to avoid having to ever trial&error which packages to specify --only-binary for), but then it fails on my actual use case, which is calling uv pip install --no-build -- ./, as it refuses to also build the local project.

It seems like a mistake for Uv to be building Numpy from source on the current host if the host does not match the desired --python-platform and it cannot guarantee that the result will be cross-compiled to the correct platform. I think Uv should raise an error here, and maybe have an option to fall back to an older version for which there are binaries.

Platform

Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6041 arm64

Version

0.8.16

Python version

3.12.11

[konstin]

Thanks for the detailed report!

For your cases --no-build is the correct choice to prevent building a package for the wrong platform.

It's possible to cross compile, for example cargo can made to cross compile with CARGO_BUILD_TARGET, so we probably don't want to make --no-build the default with --python-platform. We do however need to catch the case where the build got us an incompatible wheel, error and hint about --no-build.