## Summary
I tried to fix minor typos in the project
---------
Co-authored-by: Samuel Rigaud <rigaud@gmail.com>
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
Fixes the logic for escaping a double quoted string in PowerShell by not
escaping a backslash but escaping the Unicode double quote variants that
PowerShell treats the same as the ASCII double quotes.
<img width="685" height="99" alt="image"
src="https://github.com/user-attachments/assets/ac1368c2-d915-4e49-b67f-ac71ee0f7d46"
/>
## Test Plan
There does not seem to be any tests for this. I'm fairly new to rust but
happy to add some if someone can point me in the right direction.
---------
Co-authored-by: Aria Desires <aria.desires@gmail.com>
Hello,
# Summary
This PR makes the error message clearer when you try to install packages
into an externally managed Python environment with the `--system` flag.
Now, instead of just failing, the error explains that you're hitting
this because you explicitly used `--system`.
This closes#15639.
# Test plan
- I added a new integration test (`install_with_system_interpreter` in
`pip_install.rs`) that checks the error message includes the hint.
- I tried to run `uv pip install --system -r requirements.txt` to see
the actual error message in action, but had permission issues.
Fixes#16340
## Summary
Some package registries (PyTorch, corporate PyPI mirrors) return `403
Forbidden` when a package is not found, instead of `404 Not Found`. The
previous error message incorrectly suggested this was always an
authentication issue, causing confusion for users.
This PR updates the error hint to clarify that a 403 error could
indicate either missing authentication credentials OR that the package
doesn't exist on the index.
## Test Plan
- Updated existing snapshot test in `crates/uv/tests/it/edit.rs` to
reflect the new error message
- The change is purely a message improvement with no behavioral changes
## Changes
### Before
hint: An index URL (https://example.com/simple) could not be queried due
to a lack of valid authentication credentials (403 Forbidden).
### After
hint: An index URL (https://example.com/simple) returned a 403 Forbidden
error. This could indicate missing authentication credentials, or the
package may not exist on this index.
## Files Changed
- `crates/uv-resolver/src/pubgrub/report.rs` - Updated error message
- `crates/uv/tests/it/edit.rs` - Updated snapshot test expectation
---------
Co-authored-by: eun2ce <eun2ce@eun2ceui-MacBookPro.local>
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
fixes issue #15938
- show platform wheel hint with a concrete
`tool.uv.required-environments` example so users know how to configure
compatibility
- add `WheelTagHint::suggest_environment_marker` to pick a sensible
environment marker based on the available wheel tags
- update the `sync_required_environment_hint` integration snapshot to
expect the new multi-line hint
## Test Plan
cargo test --package uv --test it --
sync::sync_required_environment_hint
<!--
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? -->
The warning shown when `egg-info` lacks `top_level.txt` incorrectly
warns about missing `top-level.txt`
ee2649feaa/crates/uv-install-wheel/src/uninstall.rs (L179-L188)ee2649feaa/crates/uv/src/commands/pip/operations.rs (L687-L693)
The non fatal warning with incorrect filename was introduced in
https://github.com/astral-sh/uv/pull/6881 which changed previous fatal
error https://github.com/astral-sh/uv/issues/6872 with correct
`top_level.txt` output.
## Test Plan
<!-- How was it tested? -->
Updated unit test to reflect change in warning
This PR enables `--torch-backend=auto` to automatically detect Intel
GPUs. It follows up on
[#14386](https://github.com/astral-sh/uv/pull/14386).
On Windows, detection is implemented by querying the
`Win32_VideoController` class via the [WMI
crate](https://github.com/ohadravid/wmi-rs/tree/v0.16.0).
Currently, Intel GPUs (XPU) do not depend on specific driver or toolkit
versions to determine which PyTorch wheel to use.
<!--
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
HTTP1.1 [RFC 9112 -
HTTP/1.1](https://www.rfc-editor.org/rfc/rfc9112.html#name-status-line)
section 4 defines the response status code to optionally include a text
description (human readable) of the reason for the status code.
[RFC9113 - HTTP/2](https://www.rfc-editor.org/rfc/rfc9113) is the HTTP2
protocol standard and the response status only considers the [status
code](https://www.rfc-editor.org/rfc/rfc9113#name-response-pseudo-header-fiel)
and not the reason phrase, and as such important information can be lost
in helping the client determine a route cause of a failure.
As per discussion on this
[PR](https://github.com/astral-sh/uv/pull/15979) the current feeling is
that implementing the RFC9457 standard might be the preferred route.
This PR makes those changes to aid the discussion which has also been
moved to the [PEP
board](https://discuss.python.org/t/block-download-of-components-when-violating-policy/104021/1)
## Test Plan
Pulling components that violate our policy over HTTP2 and without any
RFC9457 implementation the following message is presented to the user:
<img width="1482" height="104" alt="image"
src="https://github.com/user-attachments/assets/0afcd0d8-ca67-4f94-a6c2-131e3b6d8dcc"
/>
With the RFC9457 standard implemented, below you can see the advantage
in the extra context as to why the component has been blocked:
<img width="2171" height="127" alt="image"
src="https://github.com/user-attachments/assets/25bb5465-955d-4a76-9f30-5477fc2c866f"
/>
---------
Co-authored-by: konstin <konstin@mailbox.org>
<!--
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
Fixes#16285
## Test Plan
<!-- How was it tested? -->
Sometimes a credential's `Debug` formatted value appears in tracing logs
- make sure the credential doesn't appear there.
## Test plan
Added a test case + ran
```
uv pip install --default-index $PYX_API_URL/$SOME_INDEX $SOME_PACKAGE -vv
```
With an authenticated uv client and confirmed the tokens are obfuscated.
---------
Co-authored-by: Zsolt Dollenstein <zsol.zsol@gmail.com>
## Summary
- Move parsing `UV_CONCURRENT_INSTALLS`, `UV_CONCURRENT_BUILDS` and
`UV_CONCURRENT_DOWNLOADS` to `EnvironmentOptions`
Relates https://github.com/astral-sh/uv/issues/14720
## Test Plan
- Tests with existing tests
- Add test with invalid parsing
<!--
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?
-->
Closes#15312
Closes https://github.com/astral-sh/uv/issues/16237
---------
Co-authored-by: pythonweb2 <32141163+pythonweb2@users.noreply.github.com>
Co-authored-by: Wade Roberts <wade.roberts@centralsquare.com>
## Summary
Adds the version for environment variables added in
https://github.com/astral-sh/uv/pull/16040 and
https://github.com/astral-sh/uv/pull/16125. as these were in-flight
before documentation versioning was added.
Adds ability to emit a compiler error when added in is missing for
improved reporting to the developer.
e.g. example for the ones fixed in this PR
```shell
error: missing #[attr_added_in("x.y.z")] on `UV_UPLOAD_HTTP_TIMEOUT`
note: env vars for an upcoming release should be annotated with `#[attr_added_in("next release")]`
--> crates\uv-static\src\env_vars.rs:593:15
|
593 | pub const UV_UPLOAD_HTTP_TIMEOUT: &'static str = "UV_UPLOAD_HTTP_TIMEOUT";
| ^^^^^^^^^^^^^^^^^^^^^^
error: missing #[attr_added_in("x.y.z")] on `UV_WORKING_DIRECTORY`
note: env vars for an upcoming release should be annotated with `#[attr_added_in("next release")]`
--> crates\uv-static\src\env_vars.rs:1087:15
|
1087 | pub const UV_WORKING_DIRECTORY: &'static str = "UV_WORKING_DIRECTORY";
| ^^^^^^^^^^^^^^^^^^^^
error: could not compile `uv-static` (lib) due to 2 previous errors
```
Cargo is currently recompiling uv-python on every invocation because the
minified JSON output file is getting a mod time newer than the last run.
Instead, set the mod time of the output file to the same as the input
file.
## Summary
When specifying constraints or overrides in combination with
`pylock.toml` as an input to `uv pip install`,
the error messages are not currently correct.
## Test Plan
No testing, it's a straightforward error string fix.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
- Move parsing `UV_HTTP_TIMEOUT`, `UV_REQUEST_TIMEOUT` and
`HTTP_TIMEOUT` to `EnvironmentOptions`
- Add new env varialbe `UV_UPLOAD_HTTP_TIMEOUT`
Relates https://github.com/astral-sh/uv/issues/14720
## Test Plan
Tests with existing tests
I think this is ostensively breaking, though I think the impact would be
small given this will go out in 0.9.1 and should only affect people
using pre-release Python versions.
When `3.14.0` is requested (opposed to `3.14`), we treat this as a
request for a final / stable version and ignore pre-releases.
I think this is a fairly clean way to allow users to explicitly request
the stable version.
Closes https://github.com/astral-sh/uv/issues/16175
Follows #16208
## Summary
Fixes [1633](https://github.com/astral-sh/uv/issues/16133). Preserves
comments preceding "version = ..." line when uv version --bump is ran
## Test Plan
Added IT test
---------
Co-authored-by: konsti <konstin@mailbox.org>
Example output:
```
$ uv-debug init foo -v
DEBUG uv 0.9.0+6 (d3324baf68 2025-10-08)
DEBUG Acquired shared lock for `/home/konsti/.cache/uv`
DEBUG No Python version file found in ancestors of working directory: /home/konsti/projects/foo
DEBUG Checking for Python environment at: `foo/.venv`
DEBUG Searching for default Python interpreter in managed installations or search path
DEBUG Searching for managed installations at `/home/konsti/.local/share/uv/python`
DEBUG Found managed installation `cpython-3.14.0-linux-x86_64-gnu`
DEBUG Found `cpython-3.14.0-linux-x86_64-gnu` at `/home/konsti/.local/share/uv/python/cpython-3.14.0-linux-x86_64-gnu/bin/python3.14` (managed installations)
DEBUG Using Python version `>=3.14` from default interpreter
DEBUG `git rev-parse --is-inside-work-tree` failed but didn't contain `not a git repository` in stderr for `/home/konsti/projects/foo`
DEBUG No Python version file found in ancestors of working directory: /home/konsti/projects/foo
DEBUG Writing Python versions to `/home/konsti/projects/foo/.python-version`
Initialized project `foo` at `/home/konsti/projects/foo`
DEBUG Released lock at `/home/konsti/.cache/uv/.lock`
```
First commit is refactoring, second commit is the actual change.
The h2 errors, a specific type nested in reqwest errors, all look like
they shouldn't happen in regular operations and should be retried. This
covers all `io::Error`s going through h2 (i.e., only HTTP 2
connections).
Fixes https://github.com/astral-sh/uv/issues/15916
## Summary
As new environment variables get introduced (e.g. `UV_EDITABLE`) I
thought it would useful to start tracking which release they were
introduced. I think its a common workflow to navigate to the [env var
documentation](https://docs.astral.sh/uv/reference/environment) to know
what the env var for something is but then end up in a situation where
one is using an environment variable with the wrong version of uv and
not notice immediately that its not compatible and therefore ignored.
## Test Plan
Existing tests.
The versions in `since` have all been manually reviewed to the best of
my ability for correctness.
<!--
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 pull request enables the `--directory` option to accept environment
variable: `UV_DIRECTORY`
### Motivation
Currently, the `--project` option already supports environment
variables, but --directory does not.
The motivation for this change is the same as for the --project option.
When using this option, it’s likely that the project root and the
directory containing the uv project differ. In such cases, allowing
environment variables makes it easier to avoid repeatedly specifying the
directory in commands or task runners.
### Other PRs
- PR for create `--project` option:
https://github.com/astral-sh/uv/pull/12327
## Test Plan
<!-- How was it tested? -->
### no auto testing
As with the --project option, no auto tests are included for this
change.
This is because the implementation relies on Clap’s built-in attribute
functionality, and testing such behavior would effectively mean testing
a third-party crate, which would be redundant.
As long as the compiler accepts it, things should work as expected.
### testing manually
i tested manually like [previous pull
request](https://github.com/astral-sh/uv/pull/12327)
```shell
$ cargo build --locked
./target/debug/uv init uv_directory
$ mkdir uv_directory
$ UV_DIRECTORY=uv_directory ./target/debug/uv sync
Using CPython 3.14.0rc3
Creating virtual environment at: .venv
Resolved 1 package in 15ms
Audited in 0.04ms
$ UV_DIRECTORY=uv_directory ./target/debug/uv run main.py
Hello from uv-directory!
$ ./target/debug/uv run main.py
error: Failed to spawn: `main.py`
Caused by: No such file or directory (os error 2)
```
---------
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?
-->
Hey devs, great tool as always, you're doing amazing work.
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Adds the following fields to the `[package]` table of `Cargo.toml` files
where they were missing:
```toml
rust-version = { workspace = true }
homepage = { workspace = true }
documentation = { workspace = true }
repository = { workspace = true }
authors = { workspace = true }
license = { workspace = true }
```
Most crates already had these fields, this just aligns the rest for
consistency.
This also resolves the warnings from `cargo-deny` when using `uv` crates
as dependencies in Pixi.
## Test Plan
No tests needed, this only updates metadata.
Pick up python-build-standalone tag 20251007 to add 3.14.0 final
and 3.13.8, and adjust tests.
Also, fix matching version requests with prereleases: `uvx
python@3.14.0rc3` should not be satisfied by 3.14.0 final.
Co-authored-by: Geoffrey Thomas <geofft@ldpreload.com>
The `uv-python` crate reads the checked-in download metadata to write
out a minified version to be statically included into the binary.
Sometimes, the resulting `download-metadata-minified.json` can go
missing, such as when `uv` is installed via `cargo` as a git source, and
there is an update; `cargo` will do a hard reset on the git repo it
stores in the cache, causing it to be deleted. In these instances, the
`uv-python` crate does not currently re-run its build script, because as
it happens, there was no change to the `download-metadata.json` since it
was last compiled. This causes a build error like:
```
Updating git repository `https://github.com/astral-sh/uv`
Installing uv v0.8.24 (https://github.com/astral-sh/uv?tag=0.8.24#252f8873)
Updating crates.io index
Compiling uv-version v0.8.24 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-version)
Compiling uv-git v0.0.1 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-git)
Compiling uv-build-backend v0.1.0 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-build-backend)
Compiling uv-configuration v0.0.1 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-configuration)
Compiling uv-client v0.0.1 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-client)
Compiling uv-extract v0.0.1 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-extract)
Compiling uv-workspace v0.0.1 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-workspace)
Compiling uv-python v0.0.1 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-python)
Compiling uv-requirements-txt v0.0.1 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-requirements-txt)
Compiling uv-bin-install v0.0.1 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-bin-install)
Compiling uv-publish v0.1.0 (/home/skhawtho/.cargo/git/checkouts/uv-c9e40703e19509a8/252f887/crates/uv-publish)
error: couldn't read `crates/uv-python/src/download-metadata-minified.json`: No such file or directory (os error 2)
--> crates/uv-python/src/downloads.rs:795:45
|
795 | const BUILTIN_PYTHON_DOWNLOADS_JSON: &str = include_str!("download-metadata-minified.json");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: could not compile `uv-python` (lib) due to 1 previous error
error: failed to compile `uv v0.8.24 (https://github.com/astral-sh/uv?tag=0.8.24#252f8873)`, intermediate artifacts can be found at `/home/skhawtho/.cache/cargo`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
```
This fixes the issue by also adding a `rerun-if-changed` on the
resulting minified JSON file.
Separately, this revision also changes the output directory of the
minified file to the build script's output directory via the `OUT_DIR`
environment variable, so as not to pollute the source code.
