UV seems to identify the wrong platform for torch

[snowblink14]

Summary

I'm trying to use uv sync from a uv.lock file in an open-source repo on my Mac (Apple M3 pro), but get the following error when installing torch 2.6.0:

error: Distribution `torch==2.6.0 @ registry+https://pypi.org/simple` can't be installed because it doesn't have a source distribution or wheel for the current platform

hint: You're on macOS (`macosx_15_0_x86_64`), but `torch` (v2.6.0) only has wheels for the following platforms: `manylinux_2_28_aarch64`, `manylinux1_x86_64`, `macosx_11_0_arm64`, `win_amd64`

But my mac actually should use macosx_11_0_arm64. When I use python -m venv to create another virtual environment and run pip install torch==2.6.0, it successfully installs from torch-2.6.0-cp310-none-macosx_11_0_arm64.whl.

It seems to be uv problem. When I tried to run uv pip install torch it can only install torch=2.2.2. Installing higher version results in similar error.

FYI the open source project I was playing with is https://github.com/OpenPipe/ART.

Platform

Darwin 24.4.0 arm64

Version

uv 0.7.3 (Homebrew 2025-05-07)

Python version

The above error prevents me from getting result from uv run python --version. requires-python = ">=3.10" in pyproject.toml.

[FishAlchemist]

I'm not a macOS user myself, but I dug through the uv source code a bit. It seems uv gets platform information from the MACOSX_DEPLOYMENT_TARGET environment variable, and if it's not found, it defaults to version 13.0. By the way, I recommend using --verbose. This will help whoever is assisting you in debugging the issue pinpoint the problem better. For this issue, I think you also need to provide the value of MACOSX_DEPLOYMENT_TARGET. https://docs.astral.sh/uv/configuration/environment/#macosx_deployment_target https://github.com/astral-sh/uv/blob/d4e8df9b94ac4ffc8e9214fab30d9af1bd9c80df/crates/uv-configuration/src/target_triple.rs#L243-L249 https://github.com/astral-sh/uv/blob/d4e8df9b94ac4ffc8e9214fab30d9af1bd9c80df/crates/uv-configuration/src/target_triple.rs#L753-L764

[zanieb]

For context on that default version, see https://github.com/astral-sh/uv/pull/12518

[charliermarsh]

Did you try uv cache clean? If you're seeing that, then we must've queried your interpreter at some point and seen it return x86.

[zanieb]

Can you share uv python find -v?

[snowblink14]

Thank you all! It's indeed possible that uv previously queried interpreter as x86_64 since I migrated from my old mac.

I've tried to run uv cache clean and it cleaned the cache, but the result of uv sync still result in the same error.

Result of uv python find -v:

DEBUG uv 0.7.3 (Homebrew 2025-05-07)
DEBUG Found project root: `/Users/sc/github_projects/ART`
DEBUG No workspace root found, using project root
DEBUG Reading Python requests from version file at `/Users/sc/github_projects/ART/.python-version`
DEBUG Using Python request `3.10` from version file at `.python-version`
DEBUG Searching for Python 3.10 in virtual environments, managed installations, or search path
DEBUG Found `cpython-3.10.0-macos-x86_64-none` at `/Users/sc/github_projects/ART/.venv/bin/python3` (virtual environment)
/Users/sc/github_projects/ART/.venv/bin/python3

I did try to run uv python uninstall 3.10 and uv python install 3.10 but it still installs cpython-3.10.17-macos-x86_64-none.

The uv sync verbose result is as follows:

DEBUG uv 0.7.3 (Homebrew 2025-05-07)
DEBUG Found project root: `/Users/sc/github_projects/ART`
DEBUG No workspace root found, using project root
DEBUG Acquired lock for `/Users/sc/github_projects/ART`
DEBUG Reading Python requests from version file at `/Users/sc/github_projects/ART/.python-version`
DEBUG Using Python request `3.10` from version file at `.python-version`
DEBUG Checking for Python environment at `.venv`
warning: Ignoring existing virtual environment linked to non-existent Python interpreter: .venv/bin/python3 -> python
DEBUG Searching for Python 3.10 in managed installations or search path
DEBUG Searching for managed installations at `/Users/sc/.local/share/uv/python`
DEBUG Skipping incompatible managed installation `cpython-3.13.3-macos-x86_64-none`
DEBUG Skipping incompatible managed installation `cpython-3.12.10-macos-x86_64-none`
DEBUG Skipping incompatible managed installation `cpython-3.11.12-macos-x86_64-none`
DEBUG Found managed installation `cpython-3.10.17-macos-x86_64-none`
DEBUG Found `cpython-3.10.17-macos-x86_64-none` at `/Users/sc/.local/share/uv/python/cpython-3.10.17-macos-x86_64-none/bin/python3.10` (managed installations)
Using CPython 3.10.17
Removed virtual environment at: .venv
Creating virtual environment at: .venv
DEBUG Assessing Python executable as base candidate: /Users/sc/.local/share/uv/python/cpython-3.10.17-macos-x86_64-none/bin/python3.10
DEBUG Using base executable for virtual environment: /Users/sc/.local/share/uv/python/cpython-3.10.17-macos-x86_64-none/bin/python3.10
DEBUG Released lock at `/var/folders/_n/hdcb30656qn99fhl2yryrgq40000gn/T/uv-b1a9aca7e84223b5.lock`
DEBUG Using request timeout of 30s
DEBUG Found static `pyproject.toml` for: openpipe-art @ file:///Users/sc/github_projects/ART
DEBUG No workspace root found, using project root
DEBUG Existing `uv.lock` satisfies workspace requirements
Resolved 317 packages in 67ms
error: Distribution `torch==2.6.0 @ registry+https://pypi.org/simple` can't be installed because it doesn't have a source distribution or wheel for the current platform

hint: You're on macOS (`macosx_15_0_x86_64`), but `torch` (v2.6.0) only has wheels for the following platforms: `manylinux_2_28_aarch64`, `manylinux1_x86_64`, `macosx_11_0_arm64`, `win_amd64`

I still need a way to let uv install arm64 version instead of x86_64 version for macosx, I guess.

[charliermarsh]

Is your terminal running under Rosetta or something?

[snowblink14]

Is your terminal running under Rosetta or something?

No. I was simply using the terminal under Cursor. If I switch to iTerm2 the results are the same.

Uninstalled my brew uv installation and use curl -LsSf https://astral.sh/uv/install.sh | sh instead. Now the version is uv 0.7.6 (7f3e94a09 2025-05-19) but the result is the same.

[snowblink14]

FYI I resolved this by deleting the repo, redo git clone and rerun uv sync. Now uv is able to recognize the correct aarch64 architecture for mac.

But it never worked when uv had cache and recognized the arch as x86_64 even after running uv cache clean.

[sheilahu]

Providing another data point on this. I ran into this issue after running uv sync. And this error message popped up:

error: Distribution `torch==2.8.0 @ registry+https://pypi.org/simple` can't be installed because it doesn't have a source distribution or wheel for the current platform

hint: You're on macOS (`macosx_15_0_x86_64`), but `torch` (v2.8.0) only has wheels for the following platforms: `manylinux_2_28_aarch64`, `manylinux_2_28_x86_64`, `macosx_11_0_arm64`, `win_amd64`; consider adding your platform to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels

After reading everything mentioned above, I decided to install torch directly with pip:

pip install torch==2.8.0

and it says no such version exists:

ERROR: Could not find a version that satisfies the requirement torch==2.8.0 (from versions: 2.2.0, 2.2.1, 2.2.2)

So I realized the pyproject.toml file in my directory is pointing the requirement of torch to be >= 2.8.0

[dependency-groups]
dev = [
    "torch>= 2.8.0",
]

Once I downgrade this requirement to ==2.2.2, and ran uv cache clean, I'm able to run uv sync without problem.

This error message that indicates I'm on an intel system where in reality I'm running on arm64 is quite misleading.

[zanieb]

This error message that indicates I'm on an intel system where in reality I'm running on arm64 is quite misleading.

The platform comes from the Python interpreter you're using since we need to find packages matching that. x86-64 is transparently emulatable on arm64, so it's very likely you're running an x86-64 interpreter unintentionally as was happening in https://github.com/astral-sh/uv/issues/13512#issuecomment-2889112822. If you share uv python find -v in the project, I assume you'll see an x86-64 interpreter is being used.

[ricardobeat]

For what it's worth, I just had the same issue, and it turns out uv itself was running in x86-64. This is due to carrying over homebrew from an older Intel machine, where it was running under Rosetta for compatibility at the time. You can check this with

file "$(which uv)"

It should say arm64. If it doesn't, brew uninstall uv, reinstall Homebrew and uv again, make sure you create a new venv and everything should be running arm64 versions as intended.

[BradyAJohnston]

I haven't done anything with torch so I don't know what steps occurred but I ended up running into this issue also.

There was a python installation here: ~/.local/share/uv/python/cpython-3.11.14-macos-x86_64-none/. Alongside other arm64 installs. Removing that folder completely solved the issue for me.

[nkalinov]

"Brand new" M3 was also showing a x86 arch in uv python find -v. Fixed by creating a new env with explicit python arm64 version: uv venv --python cpython-3.12.3-macos-aarch64-none after which torch automatically resolved to the latest version in uv add

Ref: https://docs.astral.sh/uv/concepts/python-versions/#requesting-a-version

[konstin]

@nkalinov Have you checked whether uv itself or your terminal are running under Rosetta 2 emulation, or whether you previously used an x86_64 Python interpreter?