## Summary
When evaluating a dependency like `member[cpu]`, we now treat `cpu` as
active for that dependency’s own conflict marker check.
Closes https://github.com/astral-sh/uv/issues/14645.
## Summary
We had no cycle handling here. I guess I naively thought the PubGrub
graph... wouldn't contain cycles? Not sure why I would think that
though!
Closes https://github.com/astral-sh/uv/issues/16930.
<!--
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
Add the explicit configuration for opting out a package out of
`--exclude-newer`. The docs mention this from
https://github.com/astral-sh/uv/pull/16854, but the actual
pyproject.toml configuration was missing. I found it from
https://github.com/astral-sh/uv/issues/12449#issuecomment-4170155721,
but this should be in the docs.
## Test Plan
uv run --only-group docs mkdocs serve -f mkdocs.yml
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| cgr.dev/chainguard/python | container | digest | `197dc1b` → `7f42e64`
|
---
### 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:eyJjcmVhdGVkSW5WZXIiOiI0My45NC4xIiwidXBkYXRlZEluVmVyIjoiNDMuMTAwLjAiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbImJ1aWxkOnNraXAtZG9ja2VyIiwiYnVpbGQ6c2tpcC1yZWxlYXNlIiwiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Patch Cargo.lock to upgrade rustls-webpki from 0.103.9 to 0.103.10,
addressing the security advisory GHSA-pwjx-qhcg-rvj4.
<!--
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? -->
```
bin/uv (rustbinary)
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 0)
┌───────────────┬─────────────────────┬──────────┬────────┬───────────────────┬───────────────────────────┬───────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │
├───────────────┼─────────────────────┼──────────┼────────┼───────────────────┼───────────────────────────┼───────────────────────────────────────────────────────────┤
│ rustls-webpki │ GHSA-pwjx-qhcg-rvj4 │ MEDIUM │ fixed │ 0.103.9 │ 0.103.10, 0.104.0-alpha.5 │ webpki: CRLs not considered authoritative by Distribution │
│ │ │ │ │ │ │ Point due to faulty matching... │
│ │ │ │ │ │ │ https://github.com/advisories/GHSA-pwjx-qhcg-rvj4 │
└───────────────┴─────────────────────┴──────────┴────────┴───────────────────┴───────────────────────────┴───────────────────────────────────────────────────────────┘
```
## Test Plan
<!-- How was it tested? -->
By updating to a newer Python version, we get a newer homeassistant
version. This change also pins the mac job to the same Python version as
the Linux job.
The way this works is
1. `release-gate` is an environment which requires approval from another
person in the organization
2. Once approved, the release can continue
3. GitHub then requires approval for every subsequent job, which we use
the `release` environment for
4. We do not require team members to approve on the `release`
environment because we run _many_ child jobs during releases
5. The `release` environment uses a deployment protection rule which
queries a GitHub App we manage
6. The GitHub App checks if the `release-gate` job was successful in the
same workflow and approves or denies accordingly
The GitHub App's source is at
https://github.com/open-security-tools/ost-environment-gate and includes
another explanation of what's going on in this process.
We don't make the release-gate block everything, so builds can start at
least while we wait for the release-gate to be approved.
## Summary
This PR fixes a problem in `uv pip install`, which currently refuses to
install debug wheels in virtual environments with debug CPythons.
Before this change, wheel parsing already preserved debug ABI suffixes
like cp313d and cp314d, but Tags::from_env only propagated free-threaded
and legacy pymalloc variants. As a result, uv would detect a debug
interpreter correctly during discovery while still generating
cp313/cp314 environment tags, causing debug-built wheels to be rejected
as incompatible.
Fix this by accepting a debug_enabled flag in Tags::from_env, mapping it
to CPythonAbiVariants::Debug, and passing the interpreter debug state
from the production call sites in uv-python and uv pip resolution.
Also update the affected tests and helpers, and add a regression test
that verifies debug CPython 3.13 generates cp313-cp313d manylinux tags.
## Test Plan
Tests run:
- cargo test -p uv-platform-tags
tags::tests::test_system_tags_debug_cpython -- --exact
- cargo test -p uv-installer
plan::tests::test_abi3_on_free_threaded_python_hint -- --exact
- cargo test -p uv-installer
plan::tests::test_gil_enabled_cpython_on_free_threaded_python_hint --
--exact
- cargo test -p uv-installer
plan::tests::test_abi3_on_regular_python_no_special_hint -- --exact
- cargo test -p uv --test it
pip_install::abi_compatibility_on_debug_python -- --exact
---------
Co-authored-by: konstin <konstin@mailbox.org>
Removes the `powerpc64-unknown-linux-gnu` target from the list of
supported build targets in `dist-workspace.toml`. The
`powerpc64le-unknown-linux-gnu` (little-endian) target remains in the
configuration.
Closes https://github.com/astral-sh/uv/issues/18798
Co-authored-by: Claude <noreply@anthropic.com>
#18767 adds a new variant to `AbiTag`, which is incompatible with the
current rkyv cache.
By the conjoined powers of this PR and
https://github.com/astral-sh/uv/pull/18796, the cache test should pass
again.
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>
Charlie Marsh