## Summary
Packages like `triton` should come from the PyTorch index, but they
don't actually vary across (e.g.) the `cu128` or `cu129` indexes.
Closes https://github.com/astral-sh/uv/issues/15446.
## Test Plan
Validate that the following pins to `cu128`, rather than `cpu`:
```
echo "vllm\ntorch==2.7.1+cu128" | cargo run pip compile --torch-backend=auto --extra-index-url https://wheels.vllm.ai/b2f6c247a9b84556a8ea0e75bb4a2db765ff3315 - --python-platform linux --python-version 3.13 -v
```
## Summary
After #15395, I realized that we didn't actually need a separate struct
for this since we now pass it around as an `Option`. (The key change
from #15395 is that when combining, we treat the options as a single
unit.)
## Summary
`match-runtime` can be explicitly specified, and if it's `false` it
should behave the same way as if it's omitted.
## Test Plan
Added snapshot test
We should not unnecessarily leak memory. Instead, we follow the general
patterns and use `Cow` for strings that can be from either a static or a
dynamic source.
## Summary
Right now, if you put `upgrade = false` in a `uv.toml`, then pass
`--upgrade-package numpy` on the CLI, we won't upgrade NumPy. This PR
fixes that interaction by ensuring that when we "combine", we look at
those arguments holistically (i.e., we bundle `upgrade` and
`upgrade-package` into a single struct, which then goes through the
`.combine` logic), rather than combining `upgrade` and `upgrade-package`
independently.
If approved, I then need to add the same thing for `no-build-isolation`,
`reinstall`, `no-build`, and `no-binary`.
## 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>
## Summary
The PyTorch team publishes ARM Linux wheels for `triton` to the PyTorch
index, which aren't available on PyPI.
## Test Plan
```
echo "torch" | cargo run pip compile - --torch-backend=cu128 --python-platform aarch64-unknown-linux-gnu --python-version 3.13
```
Previously failed because it couldn't find a compatible `triton` wheel.
As a frontend to Ruff's formatter.
There are some interesting choices here, some of which may just be
temporary:
1. We pin a default version of Ruff, so `uv format` is stable for a
given uv version
2. We install Ruff from GitHub instead of PyPI, which means we don't
need a Python interpreter or environment
3. We do not read the Ruff version from the dependency tree
See https://github.com/astral-sh/ruff/pull/19665 for a prototype of the
LSP integration.
<!--
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? -->
Currently record hashes are the hex encoded sha-256 sum. However,
they're supposed to be urlsafe-base64-nopad.
https://packaging.python.org/en/latest/specifications/recording-installed-packages/#the-record-fileFixes#15398
## Test Plan
<!-- How was it tested? -->
Build any wheel
```
uv build --wheel
```
Unpack the wheel
```
uvx wheel unpack dist/*.whl
```
Before this change, it will fail with a hash mismatch. I could confirm
with a local build that now the wheel can be unpacked with the `wheel`
command. While I don't enable hash checking when syncing, presumably it
would also currently fail.
## Summary
I've written a reasonably-long comment to explain what's going on here.
We should fix this, but it's better to continue using a
potentially-stale distribution than to panic.
Closes https://github.com/astral-sh/uv/issues/15386.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Mark `find_uv_bin_py38` test as requiring `python-eol`. Resolves one of
the issues reported in #15368.
## Test Plan
```
cargo test --profile=dev --features git --features pypi --features python --no-default-features
```
(without Python 3.8 installed)
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Venvs should not be in source distributions, and on Unix, we now reject
them for having a link outside the source directory. This PR adds a hint
for that since users were confused (#15096).
In the process, we're differentiating IO errors for format error for
uncompression generally.
Fixes#15096
## Summary
Closes#15355
This PR adds a fallback mechanism to `Shell::from_env()` that inspects
the parent process when shell environment variables are not available on
Unix-like systems.
Currently, `uv tool update-shell` fails with "the current shell could
not be determined" when environment variables like `ZSH_VERSION`,
`BASH_VERSION`, or `SHELL` are not exported. This commonly occurs in
automated environments such as GitHub Actions runners.
The fallback approach:
1. Uses `nix::unistd::getppid()` to get the parent process ID
2. Reads `/proc/<ppid>/exe` to determine the parent executable path
3. Falls back to `/proc/<ppid>/comm` if the exe symlink fails
4. Uses existing `parse_shell_from_path()` to identify the shell type
This maintains full backward compatibility - the fallback only activates
when environment variables are unavailable and an error would otherwise
occur.
## Test Plan
Tested locally with:
```bash
env -u ZSH_VERSION -u SHELL PATH="/usr/bin:/bin" $(which cargo) run -- tool update-shell --verbose
```
```text
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.30s
Running `target/debug/uv tool update-shell --verbose`
DEBUG uv 0.8.11
DEBUG Ensuring that the executable directory is in PATH: /home/user/.local/bin
DEBUG Detected parent process ID: 4147396
DEBUG Parent process executable: /usr/bin/zsh
Updated configuration file: /home/user/.zshenv
Restart your shell to apply changes
```
## Summary
This PR productionizes an idea I saw in
https://github.com/astral-sh/uv/issues/15248, which was added in Pixi:
https://github.com/prefix-dev/pixi/pull/4247. The core of the idea is
that if we install all build isolation-enabled packages first, and the
build isolation-disabled packages in a second phase, the sync is more
likely to "just work", because if all the build dependencies of the
build isolation-disabled packages are included as dependencies (as is
the case for `flash-attn`, at least), they'll be present.
This isn't really a silver bullet, because it requires that all the
build dependencies are included as first-party dependencies, and if you
have packages that want build isolation to be disabled but rely on other
packages that also require build isolation disabled, that won't work
either. I think `extra-build-dependencies` will be more robust and have
much better caching behavior, but this will get more cases right than
our current behavior, and I don't see any downsides.
Closes https://github.com/astral-sh/uv/issues/15301.
<!--
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 WindowsRunnable::from_script_path to correctly append extensions
instead of replacing them when resolving executable paths. This resolves
https://github.com/astral-sh/uv/issues/15165#issue-3304086689.
- Add add_extension_to_path helper that appends extensions properly
- Update extension resolution to use the new helper
- Add tests
## Test Plan
Added unit tests for the new and existing functionality that the change
touches. Tested manually locally on Windows.
<!-- How was it tested? -->
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
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
With this PR, we track the settings that were used to build a wheel
(`--config-settings`, plus any `extra-build-dependencies` or
`extra-build-variables`) and write those to the `.dist-info` directory
upon install. This then allows us to "reject" already-installed wheels,
if the user changes the build dependencies or `--config-settings` (or,
crucially, if they use `match-runtime = true` and the resolution
changes).
Closes https://github.com/astral-sh/uv/issues/15218.
This PR is a first step toward support for storing credentials in the
system keyring. The `keyring-rs` crate is the best option for system
keyring integration, but the latest version (v4) requires either that
Linux users have `libdbus` installed or that it is built with `libdbus`
vendored in. This is because v4 depends on
[dbus-secret-service](https://github.com/open-source-cooperative/dbus-secret-service),
which was created as an alternative to
[secret-service](https://github.com/open-source-cooperative/secret-service-rs)
so that users are not required to use an async runtime. Since uv does
use an async runtime, this is not a good tradeoff for uv.
This PR:
* Vendors `keyring-rs` crate into a new `uv-keyring` workspace crate
* Moves to the async `secret-service` crate that does not require
clients on Linux to have `libdbus` on their machines. This includes
updating `CredentialsAPI` trait (and implementations) to use async
methods.
* Adds `uv-keyring` tests to `cargo test` jobs. For `cargo test |
ubuntu`, this meant setting up secret service and priming gnome-keyring
as an earlier step.
* Removes iOS code paths
* Patches in @oconnor663 's changes from his [`keyring-rs`
PR](https://github.com/open-source-cooperative/keyring-rs/pull/261)
* Applies many clippy-driven updates
## Summary
If `match-runtime = true`, but we can't resolve a package's metadata
statically, then we can't _know_ what the runtime version of the package
will be -- because we can't resolve without building it. This PR makes
that footgun clearer by raising an error.
Closes https://github.com/astral-sh/uv/issues/15264.
<!--
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? -->
We are using UV as a library and we would like to provide an custom
reqwest client to the `RegistryClient`/`BaseClient`. We have a central
place in our repo where we configure the reqwest client to our needs
(certs, proxy, ...) and it is safer for us to just pass the same client
to UV rather than trying to reproduce the same client config with the
APIs that UV exposes.
Are you ok with that change?
## Test Plan
<!-- How was it tested? -->
## Summary
This breaks up a cycle I'm running into in incorporating the build
configuration into our cache keys. This is actually a type that ends up
in the frontend build system, etc., so I think it makes more sense here
anyway (as opposed to `uv-configuration` which tend to be our own
user-facing types).
