Summary
If you use uv python pin 3.x.y to pin to the latest patch version installed on the system, uv sync wrongly creates a venv pointing at the mutable 3.x symlink, not at 3.x.y directly, meaning that an unrelated action triggering a download of a newer 3.x.z will cause the venv to do a transparent upgrade to 3.x.z, contrary to the pin.
$ uv self version
uv 0.11.7 (x86_64-unknown-linux-gnu)
$ uv python list '>=3.14.3,<3.15-gnu'
cpython-3.14.4-linux-x86_64-gnu <download available>
cpython-3.14.3-linux-x86_64-gnu .local/share/uv/python/cpython-3.14-linux-x86_64-gnu/bin/python3.14
$ uv init pinme
Initialized project `pinme` at `/home/ubuntu/pinme`
$ cd pinme
$ uv python pin 3.14.3
Updated `.python-version` from `3.14` -> `3.14.3`
$ uv sync
Using CPython 3.14.3
Creating virtual environment at: .venv
Resolved 1 package in 2ms
Checked in 0.00ms
$ .venv/bin/python -V
Python 3.14.3
$ uvx python3.14.4 -c True
[triggers a download]
$ .venv/bin/python -V
Python 3.14.4
$ readlink .venv/bin/python
/home/ubuntu/.local/share/uv/python/cpython-3.14-linux-x86_64-gnu/bin/python3.14
$ head -n1 .venv/pyvenv.cfg
home = /home/ubuntu/.local/share/uv/python/cpython-3.14-linux-x86_64-gnu/bin
Interestingly, uv now realizes that the venv is incorrect and recreates it (hence using .venv/bin/python directly above):
$ uv run python -V
Using CPython 3.14.3
Removed virtual environment at: .venv
Creating virtual environment at: .venv
Python 3.14.3
$ readlink .venv/bin/python
/home/ubuntu/.local/share/uv/python/cpython-3.14.3-linux-x86_64-gnu/bin/python3.14
$ head -n1 .venv/pyvenv.cfg
home = /home/ubuntu/.local/share/uv/python/cpython-3.14.3-linux-x86_64-gnu/bin
I believe this is a regression between 0.11.6 and 0.11.7, almost certainly surfaced by 9aee91c (though the bug is probably somewhere else), cc @zanieb.
Platform
Linux, but also reproduces on Windows
Version
0.11.7
Python version
No response
Summary
If you use
uv python pin 3.x.yto pin to the latest patch version installed on the system,uv syncwrongly creates a venv pointing at the mutable 3.x symlink, not at 3.x.y directly, meaning that an unrelated action triggering a download of a newer 3.x.z will cause the venv to do a transparent upgrade to 3.x.z, contrary to the pin.Interestingly, uv now realizes that the venv is incorrect and recreates it (hence using .venv/bin/python directly above):
I believe this is a regression between 0.11.6 and 0.11.7, almost certainly surfaced by 9aee91c (though the bug is probably somewhere else), cc @zanieb.
Platform
Linux, but also reproduces on Windows
Version
0.11.7
Python version
No response