## Summary
Add a `--outdated` flag that queries PyPI for the latest version of each
installed tool and filters the output to only show tools with available
updates. Each outdated tool is displayed with its installed version and
a `[latest: X.Y.Z]` annotation.
The implementation reuses the existing `LatestClient` infrastructure
from `pip list --outdated`, fetching versions concurrently with progress
reporting. Up-to-date tools are omitted from the output. A
`--no-outdated` hidden flag is included for flag negation consistency.
Fixes#9309
## Test Plan
A new integration test has been created in
`crates/uv/tests/it/tool_list.rs`, and the feature has also been tested
locally.
Signed-off-by: Mikaël Barbero <mikael.barbero@eclipse-foundation.org>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
<!--
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? -->
Both `build_backend::tool_uv_build_backend_without_build_backend` and
`build_backend::tool_uv_build_backend_wrong_build_backend` fail in
offline environments because they try to download a build backend from
PyPI.
This PR conditionalizes both tests on the existing `test-pypi` feature.
## Test Plan
<!-- How was it tested? -->
Applied as a downstream patch to Fedora’s `uv` package.
## Summary
Using `.body()` meant that the request was sent without a
`Content-Type`, whereas we want to explicitly communicate that the
mint-token request is a JSON payload. Using `.json()` causes request to
send the `Content-Type` header by default.
## Test Plan
Existing coverage.
---------
Signed-off-by: William Woodruff <william@astral.sh>
<!--
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? -->
The current documentation for virtual dependencies is somewhat confusing
because it places the sentence
> "the package will be built even if a build system is not declared"
immediately after introducing `tool.uv.package = false`. This makes it
sound as if the package might still be built when `package = false` is
set.
In reality, that sentence describes the *default behavior of path
dependencies* (when `package = false` is not set). The revised wording
clarifies that:
- `package = false` → the dependency becomes virtual (its dependencies
are installed, but the package itself is not built or installed)
- otherwise → uv treats the path dependency as a normal package and will
attempt to build it, even without a `[build-system]`.
## Summary
Lockfile re-validation was iterating from the workspace roots; but for
scripts, we have no roots! This is similar to the approach we use in `uv
tree`, `uv export`, etc.
Closes https://github.com/astral-sh/uv/issues/18312.
After this, I want to figure out how to unify more of the smoke, system,
and integration tests, but this seems like a sufficient start for Termux
testing.
The difference is below the noise threshold, but it showed up in the
profiled. The code originally existed for error handling that has since
been removed.
<!--
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
torchcodec added
https://github.com/astral-sh/uv/issues/18335
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
## Summary
Handle the case where too many hardlinks were created and thus
installing packages fails.
There are cases where the file system can have a hardlinks limit and
when it's hit `uv` fails,
for example AWS EFS that has a limit of 177 hard links (
https://docs.aws.amazon.com/efs/latest/ug/troubleshooting-efs-fileop-errors.html#hardlinkerror
)
This PR address this by resetting the hardlinks when the limit is
reached (it does this by replacing the file in the cache, so new
hardlinks can be made)
There can be race conditions over the limit, but those are ok, as the
links are reset atomically so in case of race conditions the worst case
will be that the limit is reset twice, but nothing will break.
## Test Plan
Add a `install_hardlink_after_emlink` function, it successfully
reproduced the issue on my system.
The issue is that it's expensive to run as it has to generate a lot of
hardlinks
---------
Co-authored-by: Tomasz Kramkowski <tom@astral.sh>
In a warm cache situation, e.g. with `uv run`, toml parsing is by far
our slowest operation. These kinda hacky spans help debugging that. It
would be better if `toml::from_str` would be instrumented itself, but
this way we can add paths in the relevant places.
To help with cases such as https://github.com/astral-sh/uv/issues/15655.
A question is when to show this warning. I've used sources as a proxy as
URL dependencies with enabled sources are likely those controlled by the
user, and they include workspace and `git clone`d path dependencies.
The first commit is a refactoring, the second commit the implementation.
Fixes https://github.com/astral-sh/uv/issues/15740
## Summary
Replace `remove_dir_all` with `remove_virtualenv` for the tool environment creation code path.
Closes#14985
## Test Plan
Relied on existing test coverage.
---------
Co-authored-by: Tomasz Kramkowski <tomasz@kramkow.ski>
Add `with_filtered_latest_python_versions()` to tests that were using
hardcoded patch versions for latest Python releases. This makes the
tests resilient to Python version bumps by using `[LATEST]` placeholders
instead of specific version numbers like `3.12.12` or `3.10.19`.
Also use `LATEST_PYTHON_3_12` constant for constructing directory paths
in the build version upgrade tests.
renovate[bot]