Skip to content
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

Closed
jka94 opened this issue Dec 12, 2024 · 4 comments · Fixed by #9846
Closed

UV uses wrong wheel platform for package when rosetta is involved on MacOS #9836

jka94 opened this issue Dec 12, 2024 · 4 comments · Fixed by #9846
Assignees
Labels
bug Something isn't working

Comments

@jka94
Copy link

jka94 commented Dec 12, 2024

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:

  • create venv with numpy natively ( uv_arm sync )
    • importing numpy in the first venv works
    • arm wheel is in cache
  • create venv with numpy with rosetta (uv_x86 sync )
    • importing numpy causes an error due to a platform mismatch
    • no x86 wheel is in cache

Interestingly, a refresh causes the issue to happen on the arm side, so its picking up whichever wheel was downloaded first:

  • run uv_x86 sync --refresh
    • import numpy works
    • x86 wheel is in cache
    • arm wheel is now gone
  • run uv_arm sync
    • import numpy now breaks due to platform mismatch
@jka94 jka94 changed the title UV pulls in wrong wheel for package when rosetta is involved on MacOS UV uses wrong wheel platform for package when rosetta is involved on MacOS Dec 12, 2024
@konstin
Copy link
Member

konstin commented Dec 12, 2024

Can you share logs for the numpy example (uv sync -v)?

When running through rosetta, is the path to the python interpreter the same?

@jka94
Copy link
Author

jka94 commented Dec 12, 2024

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):

DEBUG uv 0.5.4 (Homebrew 2024-11-20)
DEBUG Found project root: `/Users/.../workspace/numpy_test`
DEBUG No workspace root found, using project root
DEBUG Using Python request `>=3.11` from `requires-python` metadata
DEBUG The virtual environment's Python version satisfies `>=3.11`
DEBUG Using request timeout of 30s
DEBUG Found static `pyproject.toml` for: test @ file:///Users/.../workspace/numpy_test
DEBUG No workspace root found, using project root
DEBUG Existing `uv.lock` satisfies workspace requirements
Resolved 2 packages in 1ms
DEBUG Using request timeout of 30s
DEBUG Requirement already cached: numpy==2.2.0
Installed 1 package in 14ms
 + numpy==2.2.0

pyproject.toml

[project]
name = "test"
version = "0.0.0"
requires-python = ">=3.11"

dependencies = ["numpy"]

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

@konstin konstin added the bug Something isn't working label Dec 12, 2024
@konstin
Copy link
Member

konstin commented Dec 12, 2024

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.

@charliermarsh
Copy link
Member

Maybe there's something we can include in the cache here...? I'll look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants