## Summary
This is a non-behavior-changing refactor that puts direct source
information on individual `PubGrubDependency` edges. The resulting code
is, in my opinion, a bit simpler with clearer abstractions and more
consistent handling.
## Summary
The affected code was manually implementing part of the full logic which
was already available in `settings::resolve_preview` so this PR just
makes the project validation code use this function instead.
## Test Plan
Existing test coverage.
## 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
The issue here is that once conflicts are introduced, the markers in the
lockfile get too complicated for our basic environment checks. We should
_also_ filter by supported environments here.
Closes https://github.com/astral-sh/uv/issues/18428.
## Summary
Attempt to track and preserve relative/absolute paths when read from files.
File URLs are treated as absolute. Synthetic VerbatimUrls shouldn't have
a `given`, and are treated as relative.
This means that paths passed as absolute will be output as absolute,
although they may get normalized. Paths passed as relative will be
output as relative but they may be relative to a different location (so
that they continue to work going forwards). Previously in various places
we'd either make things absolute unconditionally or relative
unconditionally.
Cases which should now be fixed:
- uv.lock - Path dependencies, indexes, and find-links were always
converted to relative paths.
- pylock.toml export (from_resolution path) - Paths were always
relativized. Now preserves the user's original format.
- pylock.toml export (from_lock path) - Relative paths from the lock
file were being converted to absolute paths. Now uses the path exactly
as stored in the lock file.
Also noteworthy is the bugfix for a windows misbehaviour. See the commit
message for some more information.
Note: For now the `uv add` side of this has been split off as a breaking change.
## Test Plan
Added missing tests, updated existing.
I believe all the changed tests are all now correct and were previously
demonstrating buggy behaviour. Well, at least if you are on board with
the idea that we should keep relative paths relative and absolute paths
and / file URLs absolute.
## Related Issues/PRs
* Closes https://github.com/astral-sh/uv/issues/15055
* Closes https://github.com/astral-sh/uv/issues/16602
* Closes https://github.com/astral-sh/uv/issues/16514
* Closes https://github.com/astral-sh/uv/pull/15870
## Summary
Once `uv audit` lands, this will be pretty confusing to users IMO.
I've changed it to "Checked" to demo-run the changes, but I'd definitely
appreciate opinions on a better term for this (scanned? validated?)
## Test Plan
Bumped so many snapshots.
---------
Signed-off-by: William Woodruff <william@astral.sh>
## Summary
This makes two changes to our handling of trove classifiers in uv's
build backend:
1. We now reject malformed trove classifiers. I've done this by adding a
`Classifier` newtype that parses and rejects anything that _looks_ wrong
(there's no formal grammar for classifiers, so this is a pretty
primitive check, but it should be enough to preempt most common user
errors). We don't use an allowlist at the moment, although in principle
we could do that as well/instead.
2. We now emit a user warning on any license classifiers, since these
have been deprecated since PEP 639 was accepted. I've added this within
`PyProjectToml::license_metadata` since in the future we'll also want to
produce a hard error when license classifiers are present _and_
new-style structured license metadata is also present. That change will
require a breaking release however.
Closes https://github.com/astral-sh/uv/issues/16354.
## Test Plan
I've added some new unit tests for this, plus an integration test for
the user warning.
---------
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
This updates the versions a bit in the new project init.
Scikit-build-core updated to 0.12+, pybind11 updated to 3+ (which allows
a small simplification), and PyO3 updated to 0.28.2+ (which is what I
was running into, it was on an old version).
I also wanted to update the gitignore, as it's missing a bunch of things
for Maturin (like `target/*` and `*.so`!), but I guess that's somewhere
else.
---------
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
`uv export` now carries selected root extras through the export graph
and simplifies `extra` markers on ordinary dependency edges, not just
optional-dependency edges. This fixes cases where --all-extras would
still emit redundant markers for requirements that are unconditional
once the chosen extras are known.
## Summary
Introduce a global preview state to reduce the amount of churn required
when adding a preview feature.
This PR also introduces a testing feature to `uv_preview` enabled for
dev builds (builds which are used for running tests among other things).
This exposes `uv_preview::test::with_features` which can be used from
other crates' unit tests to override the preview state for the duration
of a scope. `uv_preview::init` continues to exist and work in this mode
since running the integration test suite in workspace mode pulls in the
dev feature (whereas doing it in package mode, does not, IDFK).
When doing a debug or release build, the testing feature is not enabled.
The PR is based on and closes#17844.
As an example, I've converted the build backend to using global preview
as it was a place which did unit tests which needed to set the preview
state.
## Test Plan
Verification that things continue to work and that the testing feature
does not enable for debug or release builds but does enable for tests
was done manually and by running the test suite.
Additional tests were added.
---------
Co-authored-by: Claude <noreply@anthropic.com>
## 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.
When `--config-file` or `UV_CONFIG_FILE` is used, emit a `DEBUG` message
after logging is initialized so users can verify which configuration
file is active.
The existing debug log in `FilesystemOptions::from_file()` fires before
the tracing subscriber is registered, so it is silently dropped.
Closes#17182
---------
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
`uv tool install --force` will now always recreate the environment,
which I find more intuitive (and makes it a more reliable escape hatch).
Closes https://github.com/astral-sh/uv/issues/17907.
## Summary
Follows #18394. This plumbs the actual concurrency settings (rather than
their default) and removes the default impl for `Osv`.
## Test Plan
NFC.
Signed-off-by: William Woodruff <william@astral.sh>
## Summary
This switches us to OSV's batch query API for vulnerability ID lookups,
which can then be used to concurrently fetch the actual full finding
responses.
In my local testing, this yields significant speedups: from 23s on main
(before this PR) with a small project (~70 deps) to 950ms with this PR.
~~WIP, I want to think through this approach a little more.~~
See #18119
## Test Plan
Added new unit tests.
---------
Signed-off-by: William Woodruff <william@astral.sh>
Resolves#18388
When a workspace member declares `[project.scripts]` without a
`[build-system]` table or `tool.uv.package = true`, uv silently skips
installing those entry points. The warning that normally fires for the
root project was never emitted for non-root workspace members, because
the check only inspected the workspace root's `pyproject.toml`.
This diff replaces the single-project check with a loop over all
workspace members, so the warning fires for any member that has scripts
but is not packaged. The warning message now includes the package name
to make it actionable when multiple members are involved.
## Summary
The metadata cache used `VersionId` as a key, which meant that if a
package-version existed on two different indexes, we assumed identical
metadata. This turns out not to be true in some contexts, e.g., for the
linked issue with PyTorch. We now key it on `DistributionId`, which does
include the index.
Closes https://github.com/astral-sh/uv/issues/17732.
## Summary
This adds links to `uv audit`'s outputs. This required adding links to
the backing (common) Vulnerability type and pulling them from the OSV
service. OSV will always produce a link for a Vulnerability (since the
ID itself can be turned into a link), but `Vulnerability::link` itself
is optional since other services may not necessarily guarantee this.
Follows #18193.
## Test Plan
None yet.
---------
Signed-off-by: William Woodruff <william@astral.sh>
## Summary
This adds some initial output/report formatting for `uv audit`.
This is an initial blush, any feedback to align this with
rendering/formatting idioms elsewhere would be greatly appreciated!
Atop #18119.
## Test Plan
None yet.
---------
Signed-off-by: William Woodruff <william@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>
## 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.
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? -->
Charlie Marsh