-
Notifications
You must be signed in to change notification settings - Fork 986
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 uses wrong wheel platform for package when rosetta is involved on MacOS #9836
Comments
Can you share logs for the numpy example ( When running through rosetta, is the path to the python interpreter the same? |
Yes, python interpreter is a universal binary so the path used to create the venv is the same. Here are the logs for the sync that installs the x86 package with arm uv and universal binary python (package is found in cache but with wrong platform):
pyproject.toml
Exact commands: uv cache clean
uv_x86 venv --python ./universal_python3
uv_x86 sync
arch -x86_64 ./.venv/bin/python -c "import numpy; print(numpy.random.randint(2, size=10))"
# x86 works
rm -rf .venv
uv_arm venv --python ./universal_python3
uv_arm sync
./.venv/bin/python -c "import numpy; print(numpy.random.randint(2, size=10))"
# arm fails
# refresh cache with arm
rm -rf .venv
uv_arm venv --python ./universal_python3
uv_arm sync --refresh
./.venv/bin/python -c "import numpy; print(numpy.random.randint(2, size=10))"
# arm works
uv_x86 venv --python ./universal_python3
uv_x86 sync
arch -x86_64 ./.venv/bin/python -c "import numpy; print(numpy.random.randint(2, size=10))"
# x86 fails |
We cache the python interpreter platform by path, which I assume is wrong in this case because rosetta changes the interpreter platform while keeping the path intact. |
Maybe there's something we can include in the cache here...? I'll look. |
OS: Macos 15.1.1
UV: 0.5.5
python: 3.12
We currently have a situation where we occasionally need to run a python script with rosetta, which causes uv to pick the wrong packages, depending on which platform was first used. In our case the issue happens with numpy.
Steps to reproduce:
Interestingly, a refresh causes the issue to happen on the arm side, so its picking up whichever wheel was downloaded first:
The text was updated successfully, but these errors were encountered: