## Summary
This PR fixes a problem in `uv pip install`, which currently refuses to
install debug wheels in virtual environments with debug CPythons.
Before this change, wheel parsing already preserved debug ABI suffixes
like cp313d and cp314d, but Tags::from_env only propagated free-threaded
and legacy pymalloc variants. As a result, uv would detect a debug
interpreter correctly during discovery while still generating
cp313/cp314 environment tags, causing debug-built wheels to be rejected
as incompatible.
Fix this by accepting a debug_enabled flag in Tags::from_env, mapping it
to CPythonAbiVariants::Debug, and passing the interpreter debug state
from the production call sites in uv-python and uv pip resolution.
Also update the affected tests and helpers, and add a regression test
that verifies debug CPython 3.13 generates cp313-cp313d manylinux tags.
## Test Plan
Tests run:
- cargo test -p uv-platform-tags
tags::tests::test_system_tags_debug_cpython -- --exact
- cargo test -p uv-installer
plan::tests::test_abi3_on_free_threaded_python_hint -- --exact
- cargo test -p uv-installer
plan::tests::test_gil_enabled_cpython_on_free_threaded_python_hint --
--exact
- cargo test -p uv-installer
plan::tests::test_abi3_on_regular_python_no_special_hint -- --exact
- cargo test -p uv --test it
pip_install::abi_compatibility_on_debug_python -- --exact
---------
Co-authored-by: konstin <konstin@mailbox.org>
Applies a patch to use Python 3.6 compatible types in our vendored
`packaging` implementation used in the interpreter query script. Adds
Python 3.6 and 3.7 test coverage in CI.
## Summary
We need to normalize any relative managed-Python install roots before
checking whether the active environment’s interpreter is uv-managed, so
that `sync --active` reuses the environment.
Closes https://github.com/astral-sh/uv/issues/16631.
## Summary
I was [working on addressing feedback and some issues I spotted in the
centralised environments
PR](https://www.youtube.com/watch?v=5W4NFcamRhM) and I noticed that this
wrapper type was unnecessary to achieve the desired result.
## Test Plan
Existing tests.
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
bug fix, in find version 3.1 should not match 3.10
## Test Plan
<!-- How was it tested? -->
---------
Co-authored-by: konstin <konstin@mailbox.org>
Co-authored-by: Zanie Blue <contact@zanie.dev>
Update available python versions to include CPython 3.15.0a6
Update scripts used to sync pbs releases to account for recent changes
in the repo and to support running on macOS.
## Summary
This adds warnings to both our steam and sync ZIP handling on ZIP
entries that aren't "well-known." For now, "well-known" means stored
(i.e. no compression), DEFLATE, or zstd.
In practice we have duplicated codepaths for this check: one for the
"sync" (pre-downloaded) path, and one for the streaming path.
See #16911 and #17467 for context.
## Test Plan
Will update snapshots if/when they change. I'll also add a ZIP test for
this.
(Upd: added some "futzed" wheels for the ZIP tests.)
---------
Signed-off-by: William Woodruff <william@astral.sh>
Includes a few things...
- Drops preview warnings for use of `uv python upgrade` and `uv python
install --upgrade`
- Adds `--resolve-links` to `uv python find`, which I needed in test
cases to retain existing snapshots
- Fixes issues in our "Using environment ..." messages on Windows which
were incorrect
- Refactors `from_executable` for the `PythonMinorVersionLink` type
(https://github.com/astral-sh/uv/pull/17842/commits/28b2ed2525327d94fdf5372a29bbbc476d74680f)
to use the type system to prevent incorrect construction (for above)
- Removes special casing where we only upgrade links if they already
exist, which existed so preview wasn't needed on every invocation
- Fixes a bug with `PythonMinorVersionLink::exists` which returned
`true` even if the link pointed to the wrong Python installation leading
to discovery failures
Closes#12921
For `uv tool run`, we'll just use the global Python version for all
invocations without an explicit alternative request (i.e., via the
`--python` flag).
For `uv tool install`, it's a bit more complicated:
- If the tool is not installed, we'll use the global Python version
- If the tool is already installed, we won't change the Python version
unless `--reinstall` or `--python` is used
- If the tool was installed with `--python`, we won't use the global
Python version, unless the tool is uninstalled first
The behavior can be demonstrated as follows
```
$ uv python pin --global 3.12
$ uv tool install flask # uses 3.12
$ uv tool install flask # no-op
$ uv python pin --global 3.13
$ uv tool install flask # no-op
$ uv tool install flask --reinstall # uses 3.13
$ uv tool install flask -p 3.12 # uses 3.12
$ uv tool install flask # no-op
$ uv tool install flask --reinstall # uses 3.12
```
This is a little more complicated than always reinstalling when the
global Python version pin changes, but I think it's probably more
intuitive when actually using the tool. We briefly touched on this when
adding global version pins at
https://github.com/astral-sh/uv/pull/12115#discussion_r1992222278
Minor note: I need to do a self-review of this implementation, as it's a
little awkward to encode this behavior in the existing logic.
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
@zanieb in #14916 found an interesting bug. Global pin is the user
preference across projects, but if the project locally has a local pin,
it should be an authoritative constraint and end up with error. This
avoids blocking new projects that intentionally require a newer Python
version than the user’s global default. We still error on a local
`.python-version` inside the project to preserve explicit, repo-scoped
intent.
* Explicit `--python` → Always wins regardless of constraints
* Local `.python-version` → Project-scoped, errors on conflict
* Global `.python-version` → User preference, ignored if conflicts with
project. Global pins are suggestions that can be overridden by project
requirements
* Project `requires-python` → Fallback when no pins exist
Implementation :
* If a global `~/.config/uv/.python-version` conflicts with a project
`requires-python`, we ignore the pin and use the project requirement
* If a local project `.python-version` conflicts, we error, with
guidance to update the pin
* Explicit `--python` continues to override both
Now, global pins are suggestions that can be overridden by project
requirements, rather than hard constraints that block project setup.
## Test Plan
A new has been added in `sync_python_version()` along with manual
testing :
```
harshps22ugp@lab:~/projects/uv$ target/debug/uv python pin --global 3.10
Pinned `/home/harshps22ugp/.config/uv/.python-version` to `3.10`
harshps22ugp@lab:~/projects/uv$ mkdir -p /tmp/uv-global-pin && cd /tmp/uv-global-pin
harshps22ugp@lab:/tmp/uv-global-pin$ cat > pyproject.toml <<'EOF'
> [project]
> name = "project"
> version = "0.1.0"
> requires-python = ">=3.11"
> dependencies = ["anyio==3.7.0"]
> EOF
harshps22ugp@lab:/tmp/uv-global-pin$ /home/harshps22ugp/projects/uv/target/debug/uv sync
Using CPython 3.13.5
Creating virtual environment at: .venv
Resolved 4 packages in 276ms
Prepared 3 packages in 149ms
░░░░░░░░░░░░░░░░░░░░ [0/3] Installing wheels... warning: Failed to hardlink files; falling back to full copy. This may lead to degraded performance.
If the cache and target directories are on different filesystems, hardlinking may not be supported.
If this is intentional, set `export UV_LINK_MODE=copy` or use `--link-mode=copy` to suppress this warning.
Installed 3 packages in 35ms
+ anyio==3.7.0
+ idna==3.10
+ sniffio==1.3.1
harshps22ugp@lab:/tmp/uv-global-pin$ . .venv/bin/activate
(project) harshps22ugp@lab:/tmp/uv-global-pin$ python -V
Python 3.13.5
(project) harshps22ugp@lab:/tmp/uv-global-pin$
```
No error was thrown!
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Under the `special-conda-env-names` preview feature, instead, just using
our path-based logic.
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
This PR replaces `bitflags` in favour of `enumflags2` (which we already
transitively depended on) so that `PreviewFeatures` can be replaced with
`PreviewFeature` which is an enum. This clarifies intent in cases where
we only care about one specific `PreviewFeature`.
To avoid a bunch of boilerplate changes, the `Preview` wrapper has been
kept and creation now involves a `&[PreviewFeature]` in all cases. The
alternative was to have everything which initialises a `Preview` use
`BitFlags` directly and possibly to remove `Preview` entirely but this
keeps things simpler and limits the changes throughout the rest of the
codebase solely to changes which deal with the name changes (ALL_CAPS to
PascalCase) and the impact on `--show-settings` which I don't believe we
care about stability of output for?
The changes to `--show-settings` could be avoided with some custom
`Debug` implementation but that seems excessive.
This PR will impact #16452. But the changes were inspired by trying to
remove the need for that particular PR to add more runtime type
checking.
## Test Plan
Existing tests were adjusted (I also fixed some missing cases). The test
for panicking in cases which are now prevented through the use of type
changes has been dropped. All the rest of the tests were ran, snapshot
changes reviewed and applied.
## Summary
Addresses #16709. Now specifying a simple version with `--python` or
specifying a version using `--python-version` will result in the
specified version getting downloaded with a fallback to the previous
behaviour if the download fails for some transient reason or if
downloads are disabled.
The behaviour of how `--python` gets treated as `--python-version`, if a
"simple version" is specified, is kept. This means that `--python 3.7`
turns into a soft requirement. This seems at odds with how other similar
parts of UV work, but there seem to be quite a few tests which test for
this specific behaviour and I think this is best saved for a separate
issue.
## Test Plan
I added a test case which would previously fall back to the default
interpreter and warn about it.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
This reduces the churn when changing test snapshots, as insta updates
the quotes when the contents change. Instead, we decouple it by updating
the quotes in bulk here.
Created by:
```
cargo insta test --accept --force-update-snapshots
```
## Summary
Suggest using a newer uv version when a managed python installation request
fails with `NoDownloadFound`.
Before:
```
error: No interpreter found for Python ==3.14.* in managed installations or search path
```
After:
```
error: No interpreter found for Python ==3.14.* in managed installations or search path
hint: uv embeds available Python downloads and may require an update to install new versions. Consider retrying on a newer version of uv.
```
## Test Plan
Integration test added for this case.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
We were using slightly different retry code in multiple places, this PR
unifies it.
Also fixes retry undercounting in publish if the retry middleware was
involved.
---------
Co-authored-by: Tomasz Kramkowski <tom@astral.sh>
github-actions[bot]