<!--
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>
Error when a built wheel is for the wrong platform. This can happen
especially when using `--python-platform` or `--python-version` with `uv
pip install`.
Fixes#16019
When a process is running and another calls `uv cache clean` or `uv
cache prune` we currently deadlock - sometimes until the CI timeout
(https://github.com/astral-sh/setup-uv/issues/588). To avoid this, we
add a default 5 min timeout waiting for a lock. 5 min balances allowing
in-progress builds to finish, especially with larger native
dependencies, while also giving timely errors for deadlocks on (remote)
systems.
Commit 1 is a refactoring.
This branch also fixes a problem with the logging where acquired and
released resources currently mismatch:
```
DEBUG Acquired lock for `https://github.com/tqdm/tqdm`
DEBUG Using existing Git source `https://github.com/tqdm/tqdm`
DEBUG Released lock at `C:\Users\Konsti\AppData\Local\uv\cache\git-v0\locks\16bb813afef8edd2`
```
## Summary
* Updates existing references to use EnvVars where usage was missing.
* Adds missing entries to env var usages, e.g. new env var declarations
in uv-trampoline, tests, etc.
* Note: this doesn't affect trampoline sizes as the end result is the
same
* Fixes versioning of `UV_HIDE_BUILD_OUTPUT`.
## Test Plan
Existing Tests. Compiled the trampolines locally to verify zero changes
(size, binary).
## Question
Will this complicate the crates publishing release process? I'm not
certain yet if it will be an issue for uv-trampoline (non-workspace
member) to reference a uv workspace member from a bump & release
perspective wrt lock files. If so, I'll revert the uv-trampoline changes
but keep the others.
Resolves https://github.com/astral-sh/uv/issues/16616
This PR detects managed prerelease interpreters during discovery and
warns when a matching stable build is available, wiring the new helper
into `PythonInstallation::find`, `find_best`, and `find_or_download`.
Resolves https://github.com/astral-sh/uv/issues/16295
This PR updates the Conda base-environment heuristic to recognize
Pixi-managed environments by checking for the `conda-meta/pixi` marker
file. Pixi default environments now resolve as isolated child
environments instead of system installations, restoring the expected uv
pip behavior without the `--system` flag.
`.rsrc` is the idiomatic way of storing metadata and non-code resources
in PE
binaries. This should make the resulting binaries more robust as they
are no longer
dependent on the exact location of a certain magic number.
Addresses: #15022
## Test Plan
Existing integration test for `uv-trampoline-builder` + addition to
ensure robustness
to code signing.
---------
Co-authored-by: samypr100 <3933065+samypr100@users.noreply.github.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
Resolves https://github.com/astral-sh/uv/issues/16453
When `--system` is used, the debug log now reports interpreter discovery
sources in the same order they are probed, prioritising the PATH ahead
of managed installs on every platform. I also added a few unit tests
that use `DiscoveryPreferences::sources`, ensuring the log strings stay
aligned with the actual discovery sequence for both System and
OnlySystem preferences.
Zsolt Dollenstein