I initially thought I didn't need this, but in some contexts, the
workspace member name is not useful at all and I just want to iterate
over the paths without composing with `uv workspace dir --package
<name>`
Resolves https://github.com/astral-sh/uv/issues/16719
`uv add` collapses multiple spaces before inline comments in
`[project.dependencies]`, causing unrelated diffs and moving comments
onto the wrong columns. This diff captures the exact whitespace padding
that preceded each end-of-line comment when parsing the array and reuses
it when formatting.
---------
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
#12175 changed the behavior of `on_request_complete` when stderr is not
a tty to output `Downloading`/`Uploading` (via `Direction::as_str`).
This fixes it to output `Downloaded`/`Uploaded` again.
## Test Plan
Tested locally to verify new output.
Old:
```
$ uv sync --no-cache 2>&1 | tee /dev/null
Using CPython 3.14.0
Creating virtual environment at: .venv
Resolved 12 packages in 19ms
Downloading numpy (15.8MiB)
Downloading matplotlib (9.4MiB)
Downloading fonttools (4.6MiB)
Downloading pillow (6.7MiB)
Downloading kiwisolver (1.4MiB)
Downloading kiwisolver
Downloading fonttools
Downloading pillow
Downloading matplotlib
Downloading numpy
```
New:
```
$ uv sync --no-cache 2>&1 | tee /dev/null
Using CPython 3.14.0
Creating virtual environment at: .venv
Resolved 12 packages in 3ms
Downloading numpy (15.8MiB)
Downloading fonttools (4.6MiB)
Downloading matplotlib (9.4MiB)
Downloading kiwisolver (1.4MiB)
Downloading pillow (6.7MiB)
Downloaded kiwisolver
Downloaded pillow
Downloaded fonttools
Downloaded matplotlib
Downloaded numpy
```
Dependabot appears to run a proxy which intercepts all requests and adds
credentials — credentials are _not_ provided via the CLI or environment
variables and there's no way for a user to do so. This means that when
`authenticate = "always"` is used (or when the index URL is on a pyx
domain), uv will fail even though Dependabot may intercept the request
and add credentials.
See
https://github.com/dependabot/dependabot-core/#private-registry-credential-management
I'm a little wary here, in the sense that it might be silly to have a
command that does something so simple that's covered by `uv workspace
metadata`? but I think this could be stabilized much faster than `uv
workspace metadata` and makes it easier to write scripts against
workspace members.
---------
Co-authored-by: liam <liam@scalzulli.com>
Resolves https://github.com/astral-sh/uv/issues/16693
[`PEP 639`](https://peps.python.org/pep-0639/#add-license-files-key)
requires build tools to error if any user-specified
`project.license-files` glob fails to match a file, but uv currently
allows the build to succeed and produces empty `.dist-info/licenses/`
directories.
This PR enforces the spec by tracking matches for each glob during
metadata generation, raising a clear
validation error when one is unmatched.
This allows us to suggest `uv python install --upgrade 3.14` as the
canonical way to get the latest patch version of a given Python
regardless of whether it is installed already. Currently, you can do `uv
python upgrade 3.14` and it will install it, but I'd like to remove that
behavior as I find it very surprising.
I noticed this when working on
https://github.com/astral-sh/uv/pull/16697.
[PEP 639](https://peps.python.org/pep-0639/#add-license-files-key)
expects tools to ship license texts as UTF‑8, but previously `uv build`
would quietly include any binary blob listed under
`project.license-files`.
I have no clue what is going on with `rustfmt` for this file, but it
seems that when I add the check, it wants to reformat a bunch of
surrounding stuff.
The relevant part to look at is:
```rust
for license_file in &license_files {
let file_path = root.join(license_file);
let bytes = fs_err::read(&file_path)?;
if str::from_utf8(&bytes).is_err() {
return Err(ValidationError::LicenseFileNotUtf8(license_file.clone()).into());
}
}
```
where we validate all collected license files before proceeding.
---------
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
As described in https://github.com/astral-sh/uv/issues/12229, `pip
install` with `--target` or `--prefix` seem like they should install the
necessary python version if it doesn't exist, but they currently don't.
Most minimal reproduction is something like:
```
> uv python uninstall 3.13
...
> uv pip install anyio --target target-dir --python 3.13
error: No interpreter found for Python 3.13 in virtual environments, managed installations, or search path
```
This also fails without `--target`, but a venv is expected in that case,
so the with `--target`/`--prefix` is the only version that needs to be
fixed. The same mechanism occurs for `uv pip sync` as well.
## Test Plan
Added tests for install and sync that failed before fix and now pass.
---------
Signed-off-by: Mikayla Thompson <mrt@mikayla.codes>
## Summary
Fixes `--default` not creating default executable links for pre-release
Python versions.
When using `--default` with a pre-release version like `3.15.0a1`, the
code was checking `matches_installation()` against the download request
instead of the original user request. This caused the check to fail
since the download request doesn't match pre-release versions the same
way.
Changed it to use `installation.satisfies(&first_request.request)` when
`--default` is used, which checks against the original user request.
Fixes#16696
## Test Plan
Added `python_install_default_prerelease` test that installs Python 3.15
with `--default` and verifies all three executable links (`python3.15`,
`python3`, `python`) are created. The test skips gracefully if 3.15
isn't available.
All existing tests pass.
<!--
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 typo in crates/uv-virtualenv/README.md
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
No need.
Signed-off-by: bigmoonbit <bigmoonbit@outlook.com>
## Summary
Two tests were failing when run with `SHELL=fish`:
1. `create_venv_current_working_directory` failed because the "activate"
filter didn't apply properly when the venv was in the CWD. This PR fixes
the filter.
2. `tool_install_warn_path` failed because the messages are different
between fish and bash. This PR hardcodes `SHELL=fish`.
## Test Plan
CI
Follow-up from https://github.com/astral-sh/uv/pull/16690, in `uv` every
command should be using `write!(...)/writeln!(...)` with the `Printer`
abstraction instead of bypassing control with the standard printing
functions. This lint ensures that.
## Summary
This test isn't useful on non-arm64 macs, and it outright fails if
rosetta isn't installed.
## Test Plan
Run it on my rosetta-stripped macbook
Resolves https://github.com/astral-sh/uv/issues/16616
This PR detects managed prerelease interpreters during discovery and
warns when a matching stable build is available, wiring the new helper
into `PythonInstallation::find`, `find_best`, and `find_or_download`.
## Summary
1. Discussed in review of #16678 that println should be replaced by
using `printer`. The `println` pattern was pretty consistent across all
the `dir` commands, so I've updated all of them in this PR (there are
some usages of `println` outside of `uv/src/commands` that I didn't
touch -- the use cases there seemed more complex and nuanced).
2. I missed two comments in the previous PR before merging, so updates
from those are in here as well.
## Test Plan
No behavior changes, existing tests for all commands pass.
---------
Signed-off-by: Mikayla Thompson <mrt@mikayla.codes>
Addresses https://github.com/astral-sh/uv/issues/13636
Prints the path to the workspace root by default, and any of the child
packages if requested.
I looped it into the same preview flag as `workspace metadata`, given
how closely related they are.
## Summary
```
─> uv workspace dir
/Users/mikayla/code/uv/dev-envs
─> uv workspace dir --package foo-proj
/Users/mikayla/code/uv/dev-envs/foo-proj
─> uv workspace dir --package bar-proj
error: Package `bar-proj` not found in workspace.
```
## Test Plan
Unit tests added.
---------
Signed-off-by: Mikayla Thompson <mrt@mikayla.codes>
Co-authored-by: Zanie Blue <contact@zanie.dev>
Resolves https://github.com/astral-sh/uv/issues/16427
This PR updates `uv version --bump` so you can pin the exact number
you’re targeting, i.e. `--bump patch=10` or `--bump dev=42`. The
command-line interface now parses those `component=value` flags, and the
bump logic actually sets the version to the number you asked for.
This adds the scaffolding for a `uv workspace metadata` command, as an
equivalent to `cargo metadata`, for integration with downstream tools. I
didn't do much here beyond emit the workspace root path and the paths of
the workspace members. I explored doing a bit more in #16638, but I
think we're actually going to want to come up with a fairly
comprehensive schema like `cargo metadata` has. I've started exploring
that too, but I don't have a concrete proposal to share yet.
I don't want this to be a top-level command because I think people would
expect `uv metadata <PACKAGE>` to show metadata about arbitrary packages
(this has been requested several times). I also think we can do other
things in the workspace namespace to make trivial integrations simpler,
like `uv workspace list` (enumerate members) and `uv workspace dir`
(show the path to the workspace root).
I don't expect this to be stable at all to start. I've both gated it
with preview and hidden it from the help. The intent is to merge so we
can iterate on it as we figure out what integrations need.
Addresses https://github.com/astral-sh/uv/issues/15790
## Summary
After discussion, the functionality of `--project` vs `--directory` was
quite unclear in this case, so deprecating `--project` for `init` is
probably the clearest behavior option. This is a breaking change, so it
requires being under preview before being rolled out fully.
Included in the PR now:
- new feature flag (`init --project` is deprecated if `--preview` or
`--preview-features deprecate-project-for-init` are provided)
- tests (for `--directory` behavior, as well as the current warning and
future error)
- documentation updated in docs/concepts/projects/init.md
---------
Signed-off-by: Mikayla Thompson <mrt@mikayla.codes>
<!--
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
Similarly to #16529 that adds `UV_NO_GROUP`, this adds
`UV_NO_DEFAULT_GROUPS` that does the same as `--no-default-groups`. This
can be useful on the CI, to disable default groups on a job without
having to set the argument in all commands that could trigger a sync
(for instance
[here](8757b318e9/.github/workflows/main.yml (L105-L116))).
## Test Plan
Snapshot tests.
---------
Co-authored-by: samypr100 <3933065+samypr100@users.noreply.github.com>
## Summary
At present, we only have support for the detail routes (e.g.,
`https://pypi.org/simple/requests`), but not the top-level index route
(e.g., `https://pypi.org/simple/`). I need this for some downstream work
so pulling it into its own PR.
## Summary
These are present on the PyTorch index, but only at very old versions.
The PyPI versions are newer, and seemingly these don't need to be built
against CUDA, etc.
Closes https://github.com/astral-sh/uv/issues/16651.
Resolves https://github.com/astral-sh/uv/issues/16295
This PR updates the Conda base-environment heuristic to recognize
Pixi-managed environments by checking for the `conda-meta/pixi` marker
file. Pixi default environments now resolve as isolated child
environments instead of system installations, restoring the expected uv
pip behavior without the `--system` flag.
`.rsrc` is the idiomatic way of storing metadata and non-code resources
in PE
binaries. This should make the resulting binaries more robust as they
are no longer
dependent on the exact location of a certain magic number.
Addresses: #15022
## Test Plan
Existing integration test for `uv-trampoline-builder` + addition to
ensure robustness
to code signing.
---------
Co-authored-by: samypr100 <3933065+samypr100@users.noreply.github.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Now that we perform this fast-path in
`crates/uv-distribution/src/source/mod.rs`, I _think_ the fast-path here
is no longer used? In my testing, we only actually took this path when
the fast-path _already_ failed (and thus it would fail again, wasting
time).
<!--
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
Fixed a typo in the docs.
Regenerated the docs, with the fix.
<!-- What's the purpose of the change? What does it do, and why? -->
## 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)
Resolves https://github.com/astral-sh/uv/issues/16433
When `uv init` infers a project name from the working directory,
directories with characters outside the PEP 503 rules produced the
generic “Not a valid package or extra name” message that didn’t explain
the source of the problem. This change intercepts that failure, reports
whether the current or explicit target directory caused it, and tells
the user to supply an explicit `--name`.
<!--
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 PR removes the crate fs2 and updates Rust version to 1.89.
*Why?*
Crate fs2 is unmaintained for a long time now and has unfixed issues.
Especially it doesn't build on AIX, which is the reason I started fixing
it.
*How?*
I removed fs2 and replaced it by std:fs:File methods.
## Test Plan
<!-- How was it tested? -->
- I built it on Windows and AIX only.
- I did not test the artifacts.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Implement `uv cache size` to output the cache directory size in raw
bytes by default, with a `--human` option for human-readable output.
close#15821
<!-- How was it tested? -->
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
This is an enhancement that makes the cli flag `--no-sources` an
environment variable - "UV_NO_SOURCES"
Why is this a relevant change?
When working across different environments, in our case remote vs local,
we often have our packages hosted in a artifact registry but when
developing locally we build our packages from github. This results in us
using the uv.tool.sources table quite a bit however this then also
forces us to use `--no-sources` for all our remote work.
This change enables us to set an environment variable once and to never
have to type --no-sources after every uv run command again.
## Test Plan
Expanded on the current --no-sources tests, to test when
UV_NO_SOURCES=true/false the behaviour is the same as the flag.
Additionally ensured that the cli overrides the env variable.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
For https://github.com/astral-sh/uv/issues/16336. We previously weren't
telling the user which file is responsible for rebuilding.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Resolves https://github.com/astral-sh/uv/issues/16496
This PR updates the resolver so `build-system` dependency failures
surface prerelease hints even when prerelease selection is fixed. When a
build dependency only has prerelease candidates, or the requested
version explicitly includes a prerelease marker, we now emit a tailored
hint explaining that build environments can’t auto-enable prereleases
and describing how to opt in.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
Deserialize project name into both a String and a ProjectName, this way
we can keep using the normalized name elsewhere while respecting the
original name from the `pyproject.toml` file
This PR addresses issue #16547
## Test Plan
I added a new test for this, and I ran the test suite in the
`metadata.rs` file.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## 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.
It's too common to set `FORCE_COLOR` in CI which then breaks consumption
of the token.
This is actually specific to `pyx.dev`, as we print passwords without
coloring.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
<!--
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
Improve readability of progress bars by drawing the right portions in
dimmed black instead of dimmed green. This makes it much easier to
distinguish from the left (finished) part, which is drawn in green.
Fixes#6908.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
Tested locally, looks as follows:
<img width="1100" height="731" alt="white"
src="https://github.com/user-attachments/assets/2a396e96-27ef-41ed-8b03-a0de2061af12"
/>
<img width="1100" height="731" alt="black"
src="https://github.com/user-attachments/assets/85d03a3a-a1dc-4389-9e51-fd486e60e067"
/>
The `home_dir` function in std was deprecated for some years for reading
`HOME` on Windows. It has recently been fixed and undeprecated:
https://github.com/rust-lang/rust/pull/132515
Conversely, the Cargo maintainers want us to move away from the home
crate (https://github.com/rust-lang/cargo/tree/master/crates/home):
> Note: This has been fixed in Rust 1.85 to no longer use the HOME
environment variable on Windows. If you are still using this crate for
the purpose of getting a home directory, you are strongly encouraged to
switch to using the standard library's home_dir instead. It is planned
to have the deprecation notice removed in 1.87.
>
> This crate further provides two functions, cargo_home and rustup_home,
which are the canonical way to determine the location that Cargo and
rustup store their data.
>
> See rust-lang/rust#43321.
>
> > This crate is maintained by the Cargo team, primarily for use by
Cargo and Rustup and not intended for external use. This crate may make
major changes to its APIs or be deprecated without warning.
When https://github.com/lunacookies/etcetera/pull/36 merges, we can
remove the home crate from our dependency tree.
## Summary
Extend the existing GitHub Gist URL support from #15058 to handle URLs
that redirect to Gists.
`reqwest` already handled generic URL redirects for us (note this
redirects directly to the `.py` on `gist.githubusercontent.com`):
~/git/uv $ uv run
c28a4bf0cb/hello.py
hello world!
But running a URL that redirected to a Gist's "main page" (a bit.ly link
leading to a Gist, etc.) did not:
~/git/uv $ uv run
https://httpbin.org/redirect-to?url=https://gist.github.com/twilligon/4d878a4d9550a4f1df258cde1f058699
File "/tmp/scriptNodt3Q.py", line 87
<title>hello.py · GitHub</title>
But if we have `reqwest` follow redirects *before* `resolve_gist_url`,
we can handle this fine:
~/git/uv $ target/debug/uv run
https://httpbin.org/redirect-to?url=https://gist.github.com/twilligon/4d878a4d9550a4f1df258cde1f058699
hello world!
## Test Plan
I'd write an automated test but that'd require network access since
wiremock doesn't seem to support mocking specific hostnames like
`gist.github.com`. As manual tests go, I basically did the above,
testing with several redirectors to both generic and Gist URLs.
## Summary
Without this, a user who does `uv auth login ...` will retry against the
service's status endpoint forever. This probably isn't what they
intended (they probably walked away from their machine), so we end their
login initiation session after 60 retries. Since we do a retry every
second, this gives them no less than a minute to complete a login (which
should be more than enough).
## Test Plan
We don't have browser-negotiated login tests at the moment in CI, but
I've tested this locally:
```console
% ./target/debug/uv auth login pyx.dev
Logging in with https://api.pyx.dev/auth/cli/login/REDACTED
error: Login session timed out
```
(That took well over a minute, so 60s is a lower bound assuming a very
optimal network roundtrip on each poll.)
---------
Signed-off-by: William Woodruff <william@astral.sh>
* feat: reject ZIP archives with improbable filenames
Signed-off-by: William Woodruff <william@astral.sh>
* use my PR for async_zip temporarily
Signed-off-by: William Woodruff <william@astral.sh>
* update snapshot
Signed-off-by: William Woodruff <william@astral.sh>
* two more tests
Signed-off-by: William Woodruff <william@astral.sh>
* update rev
Signed-off-by: William Woodruff <william@astral.sh>
---------
Signed-off-by: William Woodruff <william@astral.sh>
Resolves https://github.com/astral-sh/uv/issues/16453
When `--system` is used, the debug log now reports interpreter discovery
sources in the same order they are probed, prioritising the PATH ahead
of managed installs on every platform. I also added a few unit tests
that use `DiscoveryPreferences::sources`, ensuring the log strings stay
aligned with the actual discovery sequence for both System and
OnlySystem preferences.
## Summary
Changes the `length` parameter to `PythonDownloadReporter::new` to an
`Option<u64>` to resolve the issue of setting a single-item reporter
length.
Resolves: #15404
## Test Plan
- build test
- ran test suite
## Summary
Upgrades to the latest Rust edition and pyo3 version.
Change initialized module to "Inline Declaration" format.
https://pyo3.rs/v0.27.1/module.html#inline-declaration
The output of `maturin new` is also updating to the new declarative
format
342239a95a
## Test Plan
Updated the relevant snapshot tests and to confirm ran
`cargo nextest run --all-features --no-fail-fast maturin`
Also used the updated template to generate a library in a different
project with
```
cargo run -- init --lib --build-backend maturin --name try-template ../_OTHER_PROJECT_/backend/try-template
```
and the generated workspace member functioned as expected.
Made to address this comment:
https://github.com/astral-sh/uv/pull/16103#discussion_r2437498249
This PR sorts the distributions collected by
`FlatIndexClient::read_from_directory` (used for `--find-links`) so
results are ordered deterministically by filename and index.
Closes https://github.com/astral-sh/uv/issues/16218
This occurs when using a mounted file system in Docker.
We're almost always removing a virtual environment to replace it, and
removing the parent directory isn't necessary for that.
Provide a good error message when the discovered workspace members
mismatch with the locked workspace members in `uv export --frozen`,
instead of panicking.
Fixes#16406
I had some qualms with https://github.com/astral-sh/uv/pull/16318
1. The snapshot was specific to uv's managed interpreter due to
inclusion of the externally-managed output. This will break downstream
distros. We either need to filter the message, or, as done here, install
a managed interpreter.
2. It had a custom filter for the interpreter path, which we shouldn't
need. If needed, we should fix that in the test context.
3. We already had an implicit hint to create a virtual environment. The
change in styling of the new hint hint following it is confusing. It's
also confusing to hint creating a virtual environment when `--system`
was used.
4. There were unresolved requested changes to the language for the
message / it didn't fit stylistic with our existing ones.
5. The message was also very confusing for a uv-managed interpreter,
which is both a "system" Python interpreter (in that it's global) and
the opposite of a "system" interpreter per UV_PYTHON_PREFERENCE.
Also problematic, but not addressed here, is that there are other
commands that display an externally-managed message, e.g., `uv pip
sync`, but #16318 was just limited to `pip install`. We should not just
implement this in one place — I'll open a tracking issue to consolidate
and reuse the logic.
Hello,
# Summary
This PR fixes the confusing error message when running `uv lock --check`
with an outdated lockfile.
Previously, the error message incorrectly stated that `--locked` was
provided, even when the user used `--check`.
Now, the error message correctly indicates which flag was used: either
`--check` or `--locked`.
This closes#14105.
# Test plan
- I updated the existing integration test (`check_outdated_lock` in
`lock.rs`) to verify the new error message includes the correct flag.
- I ran existing tests to ensure I have no introduced regressions for
other commands.
## 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.
Zanie Blue
liam
Tom Schafer
Ryan Blue
konsti
samypr100
Meitar Reihan
Mikayla Thompson
Oshadha Gunawardena
Zsolt Dollenstein
Charlie Marsh
William Woodruff
bigmoonbit
Mathieu Kniewallner
Pavel Logan Dikov
github-actions[bot]
Haaris Rahman
Les Freire
renovate[bot]
Michael Richter
chisato
Blair Allan
Christian Asch
Alexander Vandenbulcke
Clemens Brunner
twilligon
elle
Matthijs Kok
Charles-Meldhine Madi Mnemoi
Samuel Rigaud
Jordan Borean
Andrei Berenda
eun2ce
Parham MohammadAlizadeh
Björn Dahlgren
Yu, Guangye
Mark Dodgson
Mark Dodgson
Geoffrey Thomas
Harshith VH
Skyler Hawthorne
Alyssa Coghlan
Assad Yousuf
Mitchell Berendhuysen
Shunsuke Tsuchiya
Ruben Arts