-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Description
Summary
Something about our setup using tool.uv.environments made us start rejecting a package that we have successfully installed in the past.
Minimal repro:
mkdir /tmp/uv-repro
cd /tmp/uv-repro
pyenv local 3.12
python -m pip install "uv==0.10.11"
python -m uv init --python=3.12
cat >>pyproject.toml <<'EOF'
[tool.uv]
environments = [
"sys_platform == 'linux' and platform_machine == 'x86_64' and python_version == '3.12'"
]
EOF
python -m uv add --dev --index-url="https://flashinfer.ai/whl/cu130" flashinfer-jit-cache==0.5.3+cu130
We get error:
× No solution found when resolving dependencies for split (markers: python_full_version == '3.12.*' and platform_machine == 'x86_64' and sys_platform == 'linux'):
╰─▶ Because flashinfer-jit-cache==0.5.3+cu130 has no `python_full_version == '3.12.*' and platform_machine == 'x86_64' and sys_platform == 'linux'`-compatible wheels and uv-repro:dev
depends on flashinfer-jit-cache==0.5.3+cu130, we can conclude that uv-repro:dev's requirements are unsatisfiable.
And because your project requires uv-repro:dev, we can conclude that your project's requirements are unsatisfiable.
help: If you want to add the package regardless of the failed resolution, provide the `--frozen` flag to skip locking and syncing.
Going back to 0.10.10 does not trigger this error.
AI Disclosure: I originally found this issue with Claude, but did not use it to write this issue. I created the above reproduction by hand based on what it explained to me, and verified it does demonstrate the same problematic behavior we saw in our CI/CD (which was fixed by pinning uv to 0.10.10). I'm intentionally not providing the root cause analysis Claude provided, because I don't fully understand it - however, just in case it helps debugging, it pointed me to this PR as the root cause #18451.
Platform
Linux 6.17.0-1012-oem x86_64 GNU/Linux
Version
uv 0.10.11
Python version
Python 3.12.13 (also saw it with 3.12.3 and I think 3.12.8, this affected our CI stack so there were a few differing machines involved)