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>
## 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