## Summary
This is a continuation of the excellent work by @j-helland in #16452 and
#17202 and closes#15767.
This PR adds `preview-features` to `uv.toml` and `pyproject.toml`.
This field can be set to a boolean or to a list of features.
It is intended to supersede the `preview` setting itself, and conflicts
with it.
There's a little bit of complexity required to ensure that setting
either `preview` or `preview-features` is combined at the right point,
but it's also necessary to leave them split to accurately warn when a
`uv.toml` masks a `pyproject.toml` in the same directory.
Additionally there's complexity involved in making things work with
`deny_unknown_fields` and `flatten` (they're incompatible so require
manual flattening) and also this improves error messages somewhat.
Also (supersedes) closes#16452 and (supersedes) closes#17202.
## Test Plan
Tests taken from the original PR with some alterations and a bunch of
additional tests.
---------
Co-authored-by: j-helland <jonathan.w.helland@gmail.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
This PR runs [hawk](https://github.com/astral-sh/hawk) over the uv
codebase to:
1. Remove dead code (i.e., code marked as `pub` that isn't called by any
other crates).
2. Reduce visibility of symbols (i.e., to make code non-`pub` if only
called internally, etc.).
I skimmed through the changes and added exceptions where they felt
warranted (to `hawk.toml`). I've included the `hawk.toml` file in the
prior commit, but am excluding it from being committed, since it's not
at a point that we have automated tooling.
## Summary
This PR enables users to set an `exclude-newer` override on a per-index
basis.
The priority is such that global `exclude-newer-package` has highest
priority, followed by `exclude-newer` on an index, followed by global
`exclude-newer`.
Closes https://github.com/astral-sh/uv/issues/16813.
## Summary
We want to reuse this in `[[tool.uv.index]]` definitions, so it both (1)
needs to be more generic (rather than `ExcludeNewerPackage`) and (2)
needs to be accessible to more crates (so it's now in
`uv-distribution-types`).
## Summary
Tool receipts were only storing the absolute timestamp, not the relative
span. So upgrades, `--outdated`, etc., were operating off the fixed
cutoff. We now follow the approach used in the lockfile, whereby we
store the cutoff and the relative span, and use that to recompute
offsets.
## 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
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>
The following user-facing changes are included here:
- `aws-lc` is used instead of `ring` for a cryptography backend
- Expands our certificate signature algorithm support to include
ECDSA_P256_SHA512, ECDSA_P384_SHA512, ECDSA_P521_SHA256,
ECDSA_P521_SHA384, and ECDSA_P521_SHA512
- `--native-tls` is deprecated in favor of a new `--system-certs` flag,
avoiding confusion with the TLS implementation used (we use `rustls` not
`native-tls`, see prior confusion at
https://github.com/astral-sh/uv/issues/11595)
- NASM is a new build requirement on Windows, it is required by `aws-lc`
on x86-64 and i386
- `rustls-platform-verifier` is used instead of `rustls-native-certs`
for system certificate verification
- On macOS, certificate validation is now delegated to
`Security.framework` (`SecTrust`). Performance when using
`--system-certs` is improved by avoiding exporting and parsing all the
certificates from the keychain at startup.
- On Windows, certificate validation is now delegated to
`CertGetCertificateChain` and `CertVerifyCertificateChainPolicy`
- On Linux, certificate validation should be approximately unchanged
- Some previously failing chains may succeed, and some previously
accepted chains may fail; generally, this should result in behavior
closer matching browsers and other native applications
- macOS and Windows may now perform live OCSP fetches for early
revocation, which could add latency to some requests
- Empty `SSL_CERT_FILE` values are ignored (for consistency with
`SSL_CERT_DIR`)
The following internal changes are included here:
- Certificate loading has been refactored to use a newtype with helper
methods
- The certificate tests have been rewritten
- We use `webpki-root-certs` instead of `webpki-roots`, see
https://github.com/astral-sh/uv/pull/17543#discussion_r2820187691
- We request `identity` encoding for range requests, see
https://github.com/astral-sh/async_http_range_reader/pull/3#discussion_r2700194798
- Various dependencies (including forks) updates to versions which use
reqwest 0.13+
This is a replacement of #17543 with an updated description. See that
pull request for prior discussion. I've made the following changes from
the initial approach there:
- Previously, the `native-tls` TLS implementation was added which
included an OpenSSL build. We don't currently use the `native-tls`
implementation, but the `--native-tls` flag there was erroneously
updated to enable it.
- Previously, there was a `--tls-backend` flag to toggle between
`native-tls` and `rustls`. Since we currently always use `rustls`, this
is deferred to future work (if we need it at all).
- Previously, there were unintentional breaking changes to
`SSL_CERT_FILE` and `SSL_CERT_DIR` handling, including merging with the
base certificates instead of replacing them, dropping support for
OpenSSL hash-named certificate files, skipping deduplication of
certificates. Here, we retain use of `rustls-native-certs` for loading
certificates from the system as it handles these edge cases.
Closes https://github.com/astral-sh/uv/issues/17427
---------
Co-authored-by: salmonsd <22984014+salmonsd@users.noreply.github.com>
Consolidates our file copying and linking logic in `uv-fs` instead of
having a duplicate implementation in `uv-install-wheel`. This required
introducing some new abstractions in `uv-fs` to support the features
wheel installation needs.
I think this is a blocker to improving our reflink handling in
https://github.com/astral-sh/uv/pull/17753 and also generally desirable
since the copy fallback logic is complicated.
I needed this for a test, e.g., to disable a source for an extra build
dependency without disabling the source for a workspace member, and had
also seen some requests for it. I think it makes sense to allow this.
The refactor is fairly mechanical, we go from
`SourceStrategy::Enabled|Disabled` to
`NoSources::All|None|Package(names)` as we do for other options like
`NoBinary`.
Related https://github.com/astral-sh/uv/issues/17441
Resolves https://github.com/astral-sh/uv/issues/16846,
https://github.com/astral-sh/uv/issues/16813
This diff adds support for disabling `exclude-newer` for specific
packages using `<name>=false`. This allows packages
without upload dates (e.g., CPU-only PyTorch wheels from custom indices)
to be resolved when a global `exclude-newer` is set, without disabling
it globally.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
<!--
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? -->
This allows users to set the HTTP, HTTPS, and no proxy variables via the
configuration files like ~pyproject.toml~ and uv.toml.
Users can set like so:
`uv.toml`
```toml
https-proxy = "http://my_cool_proxy:10500"
http-proxy = "http://my_cool_proxy:10500"
no-proxy = [
"dontproxyme.com",
"localhost",
]
```
Resolves https://github.com/astral-sh/uv/issues/9472
## Test Plan
<!-- How was it tested? -->
It also adds a new integration test for the proxy support in
`uv-client`.
This was tested on some of our developer machines with our proxy setup
using `~/.config/uv/uv.toml` with values like:
```toml
https-proxy = "http://my_cool_proxy:10500"
http-proxy = "http://my_cool_proxy:10500"
no-proxy = [
"dontproxyme.com",
"localhost",
]
```
---------
Signed-off-by: Eli Uriegas <eliuriegas@meta.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
This also removes the file-specific targets from prettier execution
which means we're including `.json`, `.css`, and `.html` files, which
seems like an improvement.
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
I'd like to add `--torch-backend` to `uv tool`, so this PR lifts the
setting out of `[tool.uv.pip]`. Like other settings, if it's in
`[tool.uv.pip]`, it will take preference for `uv pip` operations.
<!--
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
fix: #17103
## Test Plan
The following settings will be enabled for the schema.
```toml
[tool.uv]
exclude-newer = "P7D"
```
<!--
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
Following the changes in https://github.com/astral-sh/uv/pull/16814,
documentation for
[`--exclude-newer`](https://docs.astral.sh/uv/reference/cli/#uv-sync--exclude-newer)
and
[`--exclude-newer-package`](https://docs.astral.sh/uv/reference/cli/#uv-sync--exclude-newer-package)
arguments were updated, but not their settings counterparts, so this
just updates the settings ones to closely match the arguments ones.
## Test Plan
Ran documentation locally.
Adds support for "friendly" durations like, 1 week, 7 days, 24 hours
using Jiff's parser. During resolution, we calculate this relative to
the current time and resolve it into a concrete timestamp for the
lockfile. If the span has not changed, e.g., to another relative value,
then locking again will not change the lockfile. The locked timestamp
will only be updated when the lockfile is invalidated, e.g., with
`--upgrade`. This prevents the lockfile from repeatedly churning when a
relative value is used.
## Summary
Follow up to https://github.com/astral-sh/uv/pull/15563
Closes https://github.com/astral-sh/uv/issues/13485
This is a first-pass at adding support for conditional support for Git
LFS between git sources, initial feedback welcome.
e.g.
```
[tool.uv.sources]
test-lfs-repo = { git = "https://github.com/zanieb/test-lfs-repo.git", lfs = true }
```
For context previously a user had to set `UV_GIT_LFS` to have uv fetch
lfs objects on git sources. This env var was all or nothing, meaning you
must always have it set to get consistent behavior and it applied to all
git sources. If you fetched lfs objects at a revision and then turned
off lfs (or vice versa), the git db, corresponding checkout lfs
artifacts would not be updated properly. Similarly, when git source
distributions were built, there would be no distinction between sources
with lfs and without lfs. Hence, it could corrupt the git, sdist, and
archive caches.
In order to support some sources being LFS enabled and other not, this
PR adds a stateful layer roughly similar to how `subdirectory` works but
for `lfs` since the git database, the checkouts and the corresponding
caching layers needed to be LFS aware (requested vs installed). The
caches also had to isolated and treated entirely separate when handling
LFS sources.
Summary
* Adds `lfs = true` or `lfs = false` to git sources in pyproject.toml
* Added `lfs=true` query param / fragments to most relevant url structs
(not parsed as user input)
* In the case of uv add / uv tool, `--lfs` is supported instead
* `UV_GIT_LFS` environment variable support is still functional for
non-project entrypoints (e.g. uv pip)
* `direct-url.json` now has an custom `git_lfs` entry under VcsInfo
(note, this is not in the spec currently -- see caveats).
* git database and checkouts have an different cache key as the sources
should be treated effectively different for the same rev.
* sdists cache also differ in the cache key of a built distribution if
it was built using LFS enabled revisions to distinguish between non-LFS
same revisions. This ensures the strong assumption for archive-v0 that
an unpacked revision "doesn't change sources" stays valid.
Caveats
* `pylock.toml` import support has not been added via git_lfs=true,
going through the spec it wasn't clear to me it's something we'd support
outside of the env var (for now).
* direct-url struct was modified by adding a non-standard `git_lfs`
field under VcsInfo which may be undersirable although the PEP 610 does
say `Additional fields that would be necessary to support such VCS
SHOULD be prefixed with the VCS command name` which could be interpret
this change as ok.
* There will be a slight lockfile and cache churn for users that use
`UV_GIT_LFS` as all git lockfile entries will get a `lfs=true` fragment.
The cache version does not need an update, but LFS sources will get
their own namespace under git-v0 and sdist-v9/git hence a cache-miss
will occur once but this can be sufficient to label this as breaking for
workflows always setting `UV_GIT_LFS`.
## Test Plan
Some initial tests were added. More tests likely to follow as we reach
consensus on a final approach.
For IT test, we may want to move to use a repo under astral namespace in
order to test lfs functionality.
Manual testing was done for common pathological cases like killing LFS
fetch mid-way, uninstalling LFS after installing an sdist with it and
reinstalling, fetching LFS artifacts in different commits, etc.
PSA: Please ignore the docker build failures as its related to depot
OIDC issues.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
Fix incomplete value_type attribute for default-groups field in the
ToolUv struct schema definition. The value_type was missing its value,
which should be str | list[str] to reflect that default-groups can
accept either the literal "all" or a list of group names. (#16574)
## Summary
This PR adds an `exclude-dependencies` setting that allows users to omit
a dependency during resolution. It's effectively a formalized version of
the `flask ; python_version < '0'` hack that we've suggested to users in
various issues.
Closes#12616.
## Summary
This ended up being a bit more complex, similar to `package = false`,
because we need to understand the editable status _globally_ across the
workspace based on the packages that depend on it.
Closes https://github.com/astral-sh/uv/issues/15686.
## Summary
This implements the iOS part of
https://github.com/astral-sh/uv/issues/8029
FYI: @freakboy3742
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
Create a venv with uv and run `cargo run pip install --python-platform
arm64-apple-ios pillow`. Then the iOS binary of pillow should be
installed inside the venv.
## Summary
This implements the Android part of
https://github.com/astral-sh/uv/issues/8029
FYI: @freakboy3742 @mhsmith
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
Create a venv with uv and run `cargo run pip install --python-platform
aarch64-linux-android pybase64`. Then the Android binary of pybase64
should be installed inside the venv.
We're not sure what the best way to expose the native store to users is
yet and it's a bit weird that you can use this in the `uv auth` commands
but can't use any of the other keyring provider options. The simplest
path forward is to just not expose it to users as a keyring provider,
and instead frame it as a preview alternative to the plaintext uv
credentials store. We can revisit the best way to expose configuration
before stabilization.
Note this pull request retains the _internal_ keyring provider
implementation — we can refactor it out later but I wanted to avoid a
bunch of churn here.
Picks up the work from
- #14559
- https://github.com/astral-sh/uv/pull/14896
There are some high-level changes from those pull requests
1. We do not stash seen credentials in the keyring automatically
2. We use `auth login` and `auth logout` (for future consistency)
3. We add a `token` command for showing the credential that will be used
As well as many smaller changes to API, messaging, testing, etc.
---------
Co-authored-by: John Mumm <jtfmumm@gmail.com>
## Summary
We (and I'm sure many others) are currently doing a lot of RISC-V work
in QEMU. It is possible to significantly improve the speed of
Python-related builds by taking care of the environment setup using an
AMD64 `uv` binary (bypassing binfmt/qemu-system emulation).
Some approx numbers from local testing in riscv64 Ubuntu in QEMU:
| Resolver arch | Command | Time |
| --- | --- | --- |
| riscv64 | `pip install --upgrade --break-system-packages
--index-url=https://gitlab.com/api/v4/projects/riseproject%2Fpython%2Fwheel_builder/packages/pypi/simple
openai-harmony` | 15s |
| riscv64 | `uv pip install --upgrade --system --break-system-packages
--index-url=https://gitlab.com/api/v4/projects/riseproject%2Fpython%2Fwheel_builder/packages/pypi/simple
openai-harmony` | 5s |
| amd64 | `uv pip install --python-platform=riscv64-unknown-linux
--upgrade --system --break-system-packages
--index-url=https://gitlab.com/api/v4/projects/riseproject%2Fpython%2Fwheel_builder/packages/pypi/simple
openai-harmony` | 4s |
The numbers from some larger internal packages with deeper dependency
trees are much more pronounced - 3m6 vs 43s vs 8s, in one example.
Manylinux 2.39 is specified, as it's the first (only?) RISC-V manylinux
## Test Plan
Locally, in QEMU.
`$ docker run --platform linux/riscv64 -it ubuntu:latest`, get amd64
libc into LD_LIBRARY_PATH, tests as above
## Summary
This was fixed in https://github.com/astral-sh/uv/pull/15161, then
reverted as it regressed the error handling. I've re-applied the change
here, but moved the error handling to the runtime, rather than
parse-time. I think this is slightly worse in that we no longer include
the originating source code snippet, but it at least gives us the
expected behavior :(
Closes https://github.com/astral-sh/uv/issues/15124.
## Summary
Add torch cuda 12.9 backend
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
---------
Signed-off-by: youkaichao <youkaichao@gmail.com>
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Correct typo. "uv cache clear" is not a command.
<!--
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? -->
## Test Plan
<!-- How was it tested? -->
## Summary
It would be nice if this rendered as
`[tool.uv.extra-build-dependencies]` and `[extra-build-dependencies]`
(in `uv.toml`), but this is at least correct.
Closes https://github.com/astral-sh/uv/issues/15124.
Tomasz Kramkowski