This updates async_http_range_reader to v0.11.0 to add the missing range
request bounds validation:
https://github.com/astral-sh/async_http_range_reader/pull/8.
An open question is how we want to behave when the server has an
incorrect range request implementation (while advertising range request
support). In the current implementation, it warns with the index URL, so
that the user is aware that the massive slowdown is caused by a server
advertising broken features.
Also removes a dependency where the corresponding repo was deleted.
Fixes https://github.com/astral-sh/uv/issues/18316
## Summary
The `exclude-newer-package` setting accepts `false` to exempt a specific
package from the global `exclude-newer` constraint (via
`PackageExcludeNewer::Disabled`), but this isn't documented. This PR
adds:
- A sentence in both doc comments for `exclude_newer_package` explaining
the `false` opt-out
- An example showing `false` alongside a date value
## Motivation
This came up while adding a 3-day `exclude-newer` quarantine to a
project that also uses a private registry without PEP 700 upload-time
metadata. The `false` opt-out is exactly the right mechanism, but it
took reading the source to discover it.
The `false` value is handled by the `PackageExcludeNewer::Disabled`
variant and its custom deserializer:
https://github.com/astral-sh/uv/blob/main/crates/uv-resolver/src/exclude_newer.rs
## Test plan
- Documentation-only change (doc comments in `settings.rs`)
- Verified the generated docs render correctly by checking the existing
doc generation pipeline uses these comments
## Disclaimer
Mismatch found by @alexandrukis, patch created by Claude, reviewed by
me.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
This adds two new options to `uv audit` plus their corresponding config
fields: `--ignore` and `--ignore-until-fixed`. These do pretty much what
they say on the tin:
- `--ignore ID` ignores the given vulnerability by ID, unconditionally.
Any ID (including aliases) can be used, since it's common for people to
use CVE IDs even though we consider PYSEC and OSV "more" canonical.
- `--ignore-until-fixed ID` ignores the given vulnerability by ID
*until* a fix version appears.
Both options are additive, i.e. can be passed multiple times. I've also
implemented a `[tool.uv.audit]` section that these will live under on
the config side.
Please bikeshed the naming, I'm not confident on it!
See https://github.com/astral-sh/uv/issues/18506.
## Test Plan
Added unit tests for both the CLI and config pathways.
---------
Signed-off-by: William Woodruff <william@astral.sh>
## Summary
This expands `uv workspace metadata` with many of the fields that are
found in `uv.lock` so that we have a format with information about the
dependency graph/resolution that we're willing to call stable and have
people rely upon (rather than `uv.lock` which we'd rather you don't try
to interpret).
To a first approximation you can think of this as "uv.lock but
serialized to json" but with the fields a bit more limited for now (easy
to add later).
The biggest intentional divergence with uv.lock is that we favour
encoding the dependency graph in a form that looks more like our
internal "resolve" graph, in that hopes that it will simplify the work
of anyone doing analysis on the graph (we structure our internal graph
like this for a reason).
Specifically, the `resolve` field contains the entire dependency graph,
with packages desugarred into several different nodes. There are 4 kinds
of nodes (really 3, the build nodes will only be introduced when we
establish build-dependency locking):
* packages: `mypackage==1.0.0 @ registry+https://pypi.org/simple`
* extras: `mypackage[myextra]==1.0.0 @ registry+https://pypi.org/simple`
* groups: `mypackage:mygroup==1.0.0 @ registry+https://pypi.org/simple`
* build: `mypackage(build)==1.0.0 @ registry+https://pypi.org/simple`
package nodes hold additional metadata about the package itself, and ids
of the associated extra/group/build nodes.
---
A package like this:
```toml
[project]
name = "mypackage"
version = "1.0.0"
dependencies = ["httpx"]
[project.optional-dependencies]
cli = ["rich"]
[dependency-groups]
dev = ["typing-extensions"]
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
```
will get 4 nodes with the following edges (Version and Source omitted
here for brevity):
* `mypackage`
* `httpx`
* `mypackage(build)`
* `hatchling`
* `mypackage[cli]`
* `mypackage`
* `rich`
* `mypackage:dev`
* `typing-extensions`
Note that `mypackage[cli]` has a dependency edge on `mypackage` while
`mypackage:dev` does not. This is because
`mypackage[cli]` is fundamentally an augmentation of `mypackage` while
`mypackage:dev` is just a list of packages that happens to be defined by
`mypackage`'s pyproject.toml.
The resulting nodes for `mypackage` will look something like:
<details>
<summary>json blob</summary>
```json
{
"resolve": {
"mypackage==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": "package",
"dependencies": [
{
"id": "httpx==3.6 @ registry+https://pypi.org/simple"
"marker": "sys_platform == 'linux'"
},
],
"optional_dependencies": [
{
"name": "cli",
"id": "mypackage[cli]==1.0.0 @ editable+."
},
],
"dependency_groups": [
{
"name": "dev",
"id": "mypackage:dev==1.0.0 @ editable+."
}
]
"build_system": {
"build_backend": "hatchling.build",
"id": "mypackage(build)==1.0.0 @ editable+."
}
"sdist": { ... },
"wheels": [ ... ]
},
"mypackage:dev==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": {
"group": "dev"
},
"dependencies": [
{
"id": "typing-extensions==1.2.3 @ registry+https://pypi.org/simple"
},
]
},
}
"mypackage[cli]==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": {
"extra": "cli"
},
"dependencies": [
{
"id": "rich==2.2.3 @ registry+https://pypi.org/simple"
},
{
"id": "mypackage==1.0.0 @ editable+."
},
]
},
"mypackage(build)==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": "build",
"dependencies": [
{
"id": "hatchling==3.2.3 @ registry+https://pypi.org/simple"
},
]
}
}
}
```
</details>
## Test Plan
Snapshots
## Summary
In the same vein as https://github.com/astral-sh/uv/pull/17681/, this
adds support for setting rocm7.2 as a torch backend.
I have used the following script in the comments to enumerate the
architectures.
```
$ python
Python 3.12.3 (main, Mar 3 2026, 12:15:18) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> print(torch.cuda.get_arch_list())
['gfx900', 'gfx906', 'gfx908', 'gfx90a', 'gfx942', 'gfx1030', 'gfx1100', 'gfx1101', 'gfx1102', 'gfx1200', 'gfx1201', 'gfx950', 'gfx1150', 'gfx1151']
```
## Test Plan
<!-- How was it tested? -->
---------
Co-authored-by: Charlie Marsh <crmarsh416@gmail.com>
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
I've made `uv audit`'s approach to handling extras and groups
(explicitly) subtractive: we don't support flags like `--dev` (since `uv
audit` audits everything by default); instead, we only support flags
like `--no-dev`, `--no-group`, etc., that remove items from the
to-be-audited set.
To accomplish that, I've abstracted the filtering into a new
`Lock::packages_for_audit` API (maybe there's a better location for
it?). Implementation wise, it does a BFS similar to the one used in `uv
tree`. I _think_ there's some room/opportunity for DRYing there but I
wanted to keep the PR small/local 🙂
See https://github.com/astral-sh/uv/issues/18506.
## Test Plan
None yet.
---------
Signed-off-by: William Woodruff <william@astral.sh>
Co-authored-by: konsti <konstin@mailbox.org>
Moves from a crates.io API key to trusted publishing.
Setup of trusted publishing is automated via a script which creates the
trust relationship and disables publish by API key. The main breakage
here is that now, when we add a new crate, a release will fail. The
script is invoked during `release.sh` to catch this case and supports
creating a stub crate so the release can subsequently succeed — but this
will require the release author to have a local crates.io API key with
permissions to create projects and configure publishing. I tested this
script a few times end-to-end, but would not be surprised if it bites us
in the future.
With -q, suppress informational messages but still show when an update
actually happens. With -qq, suppress all output.
Closes#18412
## Summary
Adds `stderr_important()` to `Printer` which is only suppressed with
`-qq` (silent), not `-q` (quiet). Uses this for the update success
message in `uv self update` so cron users can run with `-q` and only
get notified when an update actually occurs.
## Test Plan
A set of new tests.
---------
Co-authored-by: Tomasz (Tom) Kramkowski <tom@astral.sh>
## Summary
With `PreviewFeature::TargetWorkspaceDiscovery` enabled, `uv run` was
parsing both the current directory’s project and the target script’s
project. Parsing configuration from the current directory is undesirable
in this case, and might fail with an error if the current directory is
inaccessible.
- Fixes#18687.
- Followup to #17423.
## Test Plan
- See #18687.
---------
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
Updates the `#[attr_added_in(...)]` version annotations for two
environment variables to reflect their actual release versions:
- `PS_MODULE_PATH`: introduced in PR #17870, released in 0.10.0
- `UV_WORKING_DIR`: introduced in PR #16884, released in 0.9.14
## Test Plan
N/A - This is a documentation/annotation update with no functional code
changes.
https://claude.ai/code/session_01XMu1RyFzAPG6Rhbu19gQoi
Co-authored-by: Claude <noreply@anthropic.com>
konsti