This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [windows-version](https://redirect.github.com/microsoft/windows-rs) |
workspace.dependencies | patch | `0.1.6` → `0.1.7` |
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM, only on
Monday ( * 0-3 * * 1 ) (UTC), Automerge - At any time (no schedule
defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My41OS4wIiwidXBkYXRlZEluVmVyIjoiNDMuNTkuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiYnVpbGQ6c2tpcC1kb2NrZXIiLCJidWlsZDpza2lwLXJlbGVhc2UiLCJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This policy is derived from
https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md: We have
the problem that there are autonomous contributions, or users trying to
get the LLM to solve the hard problems, where it usually fails.
I've kept the section intentionally concise without laying out all the
branches of valid and invalid LLM usage. For example, it's totally
possible to first have the LLM write the change, review that, then
develop a design from that and iterate on it and in the end have a fully
human-understood PR. What I want to discourage is that contributors
think they can outsource e.g. the hard algorithmic parts to the LLM,
without understanding the existing structure, where the LLM currently
inevitably fails.
---------
Co-authored-by: Tomasz Kramkowski <tom@astral.sh>
## Summary
In https://github.com/astral-sh/uv/pull/18324, sys-info-rs was dropped
in favor of a more native reimplementation to provide OsType and
OsRelease.
This PR adjusts two areas for windows to match closely previous
behavior:
1. OsType should be `Windows` rather than `Windows_NT`
https://github.com/astral-sh/uv/pull/18324#discussion_r2902257834 as
seen in
https://github.com/FillZpp/sys-info-rs/blob/60ecf1470a5b7c90242f429934a3bacb6023ec4d/c/windows.c#L12.
This also matches the output of `platform.system()` in CPython.
2. OsRelease previously used `GetVersionEx` in sys-info-rs. Looking
closely, this was used primarily in
`crates/uv-python/src/interpreter.rs` and not in linehaul as linehaul
uses `platform.release()`. The problem with `GetVersionEx` is that it
returns often the wrong version due to legacy reasons (e.g. may be stuck
returning `6.2.9200`). The current implementation only returns the build
number from the registry which is prone to problems across windows older
variants. The implementation should use `RtlGetVersion` system call
which returns the current major, minor, build in the same way as
reported by `sys.getwindowsversion()` in CPython. In order to strike
balance, this switches the implementation to use four octects
`{major}.{minor}.{build}.{revision}` as recent windows versioning relies
on major, build and revision where as older versions rely on major,
minor and service pack. A windows-version crate by the same author as
windows-rs was added as it includes the correct system calls for the
windows versions.
## Test Plan
Tested manually on both Windows desktop (10, 11) and Windows Server
(2016).
## 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
Charlie Marsh