-
Notifications
You must be signed in to change notification settings - Fork 605
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uv sync
reports selecting incorrect arch for numpy wheel
#5836
Comments
I'm not the expert here, but I wonder if this is a case of https://github.com/astral-sh/uv/blob/main/docs/reference/resolver-internals.md#wheel-tags |
Does your package have a build dependency on NumPy? Does your package install successfully with |
Yes; currently I've got this encoded in the [build-system]
requires = ["setuptools>=61.0", "wheel", "numpy"]
build-backend = "setuptools.build_meta"
Not 100% sure that this is the correct sequence, but it does seem to:
|
Thanks -- that all looks correct. This is very strange. |
I'm going to fork your repo and debug based on that Action. I'm actually so pumped that you have a repro there. |
I'm actively working on this, thank you. |
## Summary We need to avoid using incompatible versions for build dependencies that are also part of the resolved environment. This is a very subtle issue, but: when locking, we don't enforce platform compatibility. So, if we reuse the resolver state to install, and the install itself has to preform a resolution (e.g., for the build dependencies of a source distribution), that resolution may choose incompatible versions. The key property here is that there's a shared package between the build dependencies and the project dependencies. Closes #5836.
Thank you for the rapid turnaround! Will test it for my case with the next release. |
I'm using
uv
version0.2.33
. The following may be related to astral-sh/rye#1206I have a fairly small python package, that comprises a C extension module, and a minimal wrapper around it. The extension module builds against
numpy
. I've recently been working to move over to usinguv
.I'm running into issues when running
uv sync
, both locally (on MacOSarm64
) as well as on GitHub (ubuntux86_64
runner), whereuv
seems to select the wrong wheel for numpy.For example, if I have a clean source tree (no
*.so
built, no.venv
, nouv.lock
), then I run:uv sync --no-cache --verbose
Then on my mac I have just seen:
... at which point I'm guessing the incorrect architecture has caused the import error in numpy.
For something similar happening on GitHub actions you can see this log, running on
x86_64
ubuntu 22.04, which has this snippet:followed by a similar unhappiness upon attempts to install numpy.
Interestingly, it seems that
uv
does consistently pick the same incorrect wheel on each platform. (Intel Mac, it seems)Whilst the
uv sync
commands both finish with non-zero exit codes, it does seem that the resulting virtualenv is usable. Including with a correctly built extension module for my library. e.g. I can immediately run:with no error. So I am wondering if actually there's just a minor logging problem wrt. the numpy wheel selected, and then there's an unrelated issue to do with building?
Full output of `uv sync --no-cache --verbose`
The text was updated successfully, but these errors were encountered: