<!--
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
Pyproject.toml index url may contain a username while lockfile doesn't.
Treat it as the same index to prevent unintended package updates
Fixes#16436
---------
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
Follow redirects for `uv publish`. Related issue:
https://github.com/astral-sh/uv/issues/17126.
## Test Plan
<!-- How was it tested? -->
Added a unit test to test the custom redirect logic.
---------
Co-authored-by: konstin <konstin@mailbox.org>
## 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.
## Summary
This partially addresses #17076 by adding `value_hint` to various
arguments.
For cases where an option takes a path to either specifically a file or
a directory directory, `ValueHint::FilePath` and `ValueHint::DirPath`
are used respectively to try to limit the amount of noise presented by
completions in shells which support it.
For cases where a URL (and only a URL, not a path) can be supplied,
`ValueHint::Url` is used.
For cases where a python interpreter is to be specified,
`ValueHint::CommandName` is used which will tab complete from `$PATH` by
default, but will fall back to completing executable filenames if you
start typing a path.
Finally, for the many cases where there is no built in completion which
would make sense, and where default completion of a path would make no
sense (e.g. a package name, or version specifier, or date)
`ValueHint::Other` is used to explicitly disable completion.
## Test Plan
Manually tested a bunch of these. These _could_ be automated in the
sense that we could snapshot the completion from zsh but I've not
thought about how that could be done yet.
Split out from https://github.com/astral-sh/uv/pull/17110
Indent multiline error messages properly, and add a test with a
multiline context and a context below since that combination isn't
captured atm.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Closes https://github.com/astral-sh/uv/issues/17083
Previously having `UV_GIT_LFS` set would cause an error when adding a
non-git requirement such as ```error: `requirement` did not resolve to a
Git repository, but a Git extension (`--lfs`) was provided.```
## Test Plan
Additional test has been added.
## Summary
Fix#16859 by falling back to simply creating the lock file and then
attempting to apply permissions in cases where the temporary lockfile
cannot be renamed without overwriting (persist_noclobber) due to lack of
underlying support from the filesystem.
I've also improved the error handling.
## Test Plan
Manually on MacOS with an ExFAT partition.
~~~ bash session
$ hdiutil create -size 1g -fs ExFAT -volname EXFATDISK exfat.dmg
$ hdiutil attach exfat.dmg
$ cd /Volumes/EXFATDISK
$ uv init --bare --cache-dir build/uv/cache -v
~~~
<!--
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
Updates the `spdx` dependency from 0.12.x to the latest release, 0.13.2.
https://github.com/EmbarkStudios/spdx/blob/0.13.2/CHANGELOG.md
Here in uv upstream, this just helps keep dependencies up to date; there
isn’t any other particular specific motivation or benefit. Downstream in
Fedora, this change allows me to avoid maintaining a `rust-spdx0.12`
compat package.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
`cargo nextest run -- --skip python_install::python_install_pyodide`
<!--
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"
```
## Summary
Given `uv tool install {name}@latest`, we make revalidation requests for
`{name}`, but we don't actually add a "latest" constraint when resolving
-- we just assume that since the package is unpinned, and we're fetching
the latest available versions, the resolver will select the latest
version.
However, imagine a package in which the latest version requires Python
3.13 or later, but prior versions support Python 3.9 and up. If we
happen to select Python 3.9 ahead of resolution, and the user requests
`{name}@latest`, we would backtrack to the non-latest version due to the
Python mismatch.
This PR modifies `uv tool install` and `uv tool run` to first determine
the latest version, then provide it as a constraint when resolving.
This works fine now
```
❯ docker run --rm -it ghcr.io/astral-sh/uv:alpine sh -c "uv python install 3.14"
Installed Python 3.14.2 in 2.77s
+ cpython-3.14.2-linux-aarch64-musl (python3.14)
```
* Use `is_transient_network_error` as we do in all other cases, see also
https://github.com/astral-sh/uv/pull/16245
* Don't report success in the progress reporter if the upload failed
Closes https://github.com/astral-sh/uv/issues/17095
This also stabilizes the Alpine version for users that do not choose to
pin it. We could add this to the build matrix separately to avoid that,
but I think that's okay?
## Summary
Remove duplication in `report_dry_run` by making `Changelog` support
both local and remote dists. This is in support of #16653 and will form
a new basis for #16981.
This also involved refactoring `InstallLogger` and its implementations
to support dry run logging.
Additionally includes some minor refactoring in `SummaryInstallLogger`
and a fix to `InstalledVersion`.
See https://github.com/astral-sh/uv/compare/tk/dry-run-refactor for an
alternative approach (although obviously comes with some caveats).
## Test Plan
There are already quite a few tests which cover the output and they
pass. Manual testing was used to ensure styling stayed consistent.
## Summary
`uv cache size` can be quite slow. Here i use
https://github.com/sharkdp/diskus to walk the cache directory with in
multiple threads.
Add cli option to set the number of threads and default to `
std:🧵:available_parallelism()` or 1.
## Test Plan
Added cli statement with info log test.
I believe this is a fair test, where i set cache dir to a large
directory.
```bash
matthew@matthew-main ~/develop/personal/uv [14:17:50] [±cache-size-speed-up ✓▴]
> $ uv cache size --preview-features cache-size -H --cache-dir ~/develop/ [±cache-size-speed-up ✓▴]
75.7GiB
matthew@matthew-main ~/develop/personal/uv [14:18:24]
> $ hyperfine 'uv cache size --preview-features cache-size -H --cache-dir ~/develop/' 'target/debug/uv cache size --preview-features cache-size -H --cache-dir ~/develop/' [±cache-size-speed-up ✓▴]
Benchmark 1: uv cache size --preview-features cache-size -H --cache-dir ~/develop/
Time (mean ± σ): 1.059 s ± 0.014 s [User: 0.171 s, System: 0.884 s]
Range (min … max): 1.048 s … 1.097 s 10 runs
Benchmark 2: target/debug/uv cache size --preview-features cache-size -H --cache-dir ~/develop/
Time (mean ± σ): 413.8 ms ± 17.1 ms [User: 5789.2 ms, System: 1682.0 ms]
Range (min … max): 386.3 ms … 441.6 ms 10 runs
Summary
target/debug/uv cache size --preview-features cache-size -H --cache-dir ~/develop/ ran
2.56 ± 0.11 times faster than uv cache size --preview-features cache-size -H --cache-dir ~/develop/
```
<!--
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.
## Summary
This PR explicitly sets the entry type for files in an sdist. This
changes the entry type from `AREGTYPE` (the 'legacy' regular file type)
to `REGTYPE` (the 'normal' regular file type) in the generated tar.
This change works around a bug in the python `tarfile` module that
causes all entries after a certain point in the tar to be silently
ignored if any entry matches some very specific conditions. In `maturin`
this was very visible since the `PKG-INFO` was written at the very end
so `twine check` would loudly complain that the `PKG-INFO` was missing
and that the sdist was invalid. In `uv` the `PKG-INFO` is written at the
beginning so this issue is unlikely to be caught.
Note that this change does mean that sdists created with newer versions
of the uv build backend will not be byte-for-byte identical with sdists
from an older version.
See https://github.com/PyO3/maturin/issues/2855#issuecomment-3546501132
## Test Plan
This is the same as the change that was made in maturin to work around
the same issue
---------
Co-authored-by: konstin <konstin@mailbox.org>
Follows #16814 updating the test cases with Claude so that the
timestamps and durations are on the boundary of package versions so we
see actual version changes in the lockfile.
<!--
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
Gate a few more tests on the `pypi` feature. All of these fail in
offline environments because they try to communicate with PyPI.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
Applied as a patch to Fedora’s `uv` package, version 0.9.16.
Fixed https://github.com/astral-sh/uv/issues/16821
This is already explained in the guide, but it was missing from the
reference docs.
---------
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
Update the `UV_VERSION`, such that a `copy-to-clipboard` action and
pasting into a `.gitlab-ci.yml` is not 4 minor versions behind, as it
happened to me a couple of times.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
I ran `mkdocs serve` and it worked (I literally only changed one
character)
<!-- How was it tested? -->
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.
Resolves#16777
## Summary
When a command fails, users sometimes add --verbose after the package
name (e.g., uvx foo --verbose) instead of before it (e.g., uvx --verbose
foo). This adds a hint that suggests moving --verbose before the
command.
The hint appears when a verbose flag is detected in the subcommand
arguments and the command fails to resolve. It works for both uvx and uv
tool run.
## Test Plan
Tested by running:
uvx foo-does-not-exist --verbose - shows the hint
uv tool run foo-does-not-exist --verbose - shows the hint
The hint only appears when verbose flags are detected, and the message
shows the correct command format.
## Screenshot
<img width="920" height="34" alt="image"
src="https://github.com/user-attachments/assets/f6c303f6-b5e6-441f-8d8d-9f5e6ab87c87"
/>
Open to feedback and happy to make changes as needed! 💯
---------
Co-authored-by: Tomasz (Tom) Kramkowski <tom@astral.sh>
<!--
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? -->
Nushell activation now computes the venv root dynamically via path self
for relocatable venvs, while non-relocatable venvs still embed a quoted
absolute path
Still keep `activate.csh` (maybe delete is also an option)
close https://github.com/astral-sh/uv/issues/16973
<!-- How was it tested? -->
It'd be nice to avoid churn for contributors. This is a pretty frequent
cause of CI failures and I don't think we really need to have the
reference documentation committed.
## Summary
There are a class of outcomes whereby an index might not be included in
"allowed indexes", but could still correctly appear in a lockfile. In
the linked case, we have two `default = true` indexes, and one of them
is also named. We omit the second `default = true` index from the list
of "allowed indexes", but since it's named, a dependency can reference
it explicitly. We handle this correctly for `project.dependencies`, but
the handling was incorrectly omitting dependency groups.
Closes https://github.com/astral-sh/uv/issues/16843.
Error when a built wheel is for the wrong platform. This can happen
especially when using `--python-platform` or `--python-version` with `uv
pip install`.
Fixes#16019
Resolves https://github.com/astral-sh/uv/issues/16833
`uv self update` could error with a better message if it knows the user
has installed it with brew. This diff adds an `InstallSource` we can use
the detect where a `uv` binary comes from and augment error messages
with better context. We're only adding brew for now, but it could easily
be extend with other detection heuristics.
## Summary
Given `bump-workspace-crate-versions.py` will bump all crates, we also
need to update uv-trampoline lockfile references to those new versions
(for uv-static, uv-macros) after
https://github.com/astral-sh/uv/pull/16950.
## Test Plan
Ran release script manually and verify uv-trampoline lockfile is up to
date after the changes from bump-workspace-crate-versions.py
When a process is running and another calls `uv cache clean` or `uv
cache prune` we currently deadlock - sometimes until the CI timeout
(https://github.com/astral-sh/setup-uv/issues/588). To avoid this, we
add a default 5 min timeout waiting for a lock. 5 min balances allowing
in-progress builds to finish, especially with larger native
dependencies, while also giving timely errors for deadlocks on (remote)
systems.
Commit 1 is a refactoring.
This branch also fixes a problem with the logging where acquired and
released resources currently mismatch:
```
DEBUG Acquired lock for `https://github.com/tqdm/tqdm`
DEBUG Using existing Git source `https://github.com/tqdm/tqdm`
DEBUG Released lock at `C:\Users\Konsti\AppData\Local\uv\cache\git-v0\locks\16bb813afef8edd2`
```
This was discovered by https://github.com/astral-sh/uv/pull/16074, where
the wrong tag now fails the Pyston integration test.
I'm not sure what the exact schema of the cache tag is, but since the
project is dead, I don't expect any new non-matching versions to follow.
Clarify `--project` flag help text to indicate project discovery
Update the help text for `--project` from "Run the command within
the given project directory" to "Discover a project in the given
directory" to better reflect its actual behavior.
The `--project` flag affects file discovery (pyproject.toml, uv.toml,
etc.) but does not change the working directory. Users should use
`--directory` for changing the working directory.
Fixes#16718
## Summary
Inform users who encounter #16879 that `uv pip debug` is currently
intentionally not implemented.
## Test Plan
Added an integration test for the warning, ran the test suite.
## Summary
This change updates the guide about integration with pytorch to include
the CUDA 13.0 variant.
## Test Plan
I generated the documentation and verified that it looked correct.
Fixes https://github.com/astral-sh/uv/issues/16447
Passing this around explicitly uncovers some behaviors where we pass
e.g. the credentials store to reading the lockfile. The changes in this
PR should preserve the existing behavior for now, they only make the
locations we read from more explicit.
Labeling this PR as "Enhancement" instead of "Internal" in case this
changes behavior when it shouldn't have.
## Summary
Like in `uv.lock`, we should omit artifacts that are filtered out by
`--no-binary` or by the target platform tags.
Closes https://github.com/astral-sh/uv/issues/13413.
## Summary
When the test suite panics due to a missing python version, it now
prints some helpful information to guide users to `cargo run python
install` and `CONTRIBUTING.md`
~~~
---- pip_sync::incompatible_build_constraint stdout ----
thread 'pip_sync::incompatible_build_constraint' (19737) panicked at
crates/uv/tests/it/common/mod.rs:1793:17:
Could not find Python 3.9 for test
Try `cargo run python install` first, or refer to CONTRIBUTING.md
~~~
## Test Plan
Uninstalled python3.9 and ran tests which depended on it.
## Summary
Fix#16906 by pruning modules or submodules which are already included
(either directly, or through a parent).
Generates warnings when this happens.
Example:
```bash session
$ uv build
Building source distribution (uv build backend)...
warning: Ignoring redundant module name(s): test_lib.bar test_lib test_lib.bar.baz test_lib.baz
Building wheel from source distribution (uv build backend)...
Successfully built dist/test-0.1.0.tar.gz
Successfully built dist/test-0.1.0-py3-none-any.whl
```
## Test Plan
Added some unit tests for the pruning function and one for the whole
build backend. Added an integration test for the warnings. Ran the full
test suite. Manually tested.
The unit test for the function doesn't cater for the fact that it
doesn't guarantee an order at the moment. I think this is fine.
---------
Co-authored-by: konsti <konstin@mailbox.org>
## Summary
* Updates existing references to use EnvVars where usage was missing.
* Adds missing entries to env var usages, e.g. new env var declarations
in uv-trampoline, tests, etc.
* Note: this doesn't affect trampoline sizes as the end result is the
same
* Fixes versioning of `UV_HIDE_BUILD_OUTPUT`.
## Test Plan
Existing Tests. Compiled the trampolines locally to verify zero changes
(size, binary).
## Question
Will this complicate the crates publishing release process? I'm not
certain yet if it will be an issue for uv-trampoline (non-workspace
member) to reference a uv workspace member from a bump & release
perspective wrt lock files. If so, I'll revert the uv-trampoline changes
but keep the others.
See https://github.com/astral-sh/uv/pull/16944
The `crates.io` publish succeeded and is not idempotent (i.e., it'll
fail on another publish attempt) so we will skip it for a re-run of the
release workflow.
## Summary
This broke the release and I haven't figured out why yet.
## Test Plan
Blame my past self.
Signed-off-by: William Woodruff <william@astral.sh>
## 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
If you have requirements files that are included multiple times, we can
avoid going back to disk. This also guards against accidental repeated
reads on standard input streams.
## Summary
Currently we do not include a Windows manifest on the uv binary for
windows builds. This can cause problems such as the one in
https://github.com/astral-sh/uv/issues/16877 which can limit what uv can
do for some Windows operations (e.g. symlinks) that can have
restrictions imposed by the OS unbeknownst to us and make it none
obvious to isolate the issue.
Given we already do this for the `uv-trampoline`, we should also do it
for uv. In the case of uv, I opted for explicit entries in the manifest
rather than using the defaults embed_manifest crate provides which are
not appropriate in all general cases.
The manifest now includes declarations for:
* Explicit "system" codepage declaration to retain backwards compat with
previous uv releases. We should move to utf-8 codepage in the future to
align with `uv-trampoline`, but it's arguably a breaking change in rare
cases. We shouldn't have issues with using utf-8 as we don't really rely
on *A calls to begin with.
* Explicit Windows 10+ support to ensure the executables are not treated
as a legacy, preventing application compatibility layers being wrongly
applied to it all the way back to NT 6.0 (Windows Vista). Note, other
Windows compatibility entries do not imply support, rather they imply
awareness as a preventive measure.
* Long Path support to avoid Windows operations assuming
[MAX_PATH](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation)
applies. This still requires the system to have long paths enabled via
``HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem@LongPathsEnabled``
dword being set to ``1`` (see
[ref](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation#registry-setting-to-enable-long-paths)).
* Standard invoker execution levels for CLI applications to disable UAC
virtualization after including the manifest.
The resulting manifest is the following
```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
<assemblyIdentity name="uv" type="win32" version="0.9.13.0"></assemblyIdentity>
<asmv3:trustInfo>
<asmv3:security>
<asmv3:requestedPrivileges>
<asmv3:requestedExecutionLevel level="asInvoker" uiAccess="false"></asmv3:requestedExecutionLevel>
</asmv3:requestedPrivileges>
</asmv3:security>
</asmv3:trustInfo>
<asmv3:application>
<asmv3:windowsSettings>
<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
</asmv3:windowsSettings>
</asmv3:application>
<ms_compatibility:compatibility xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
xmlns="urn:schemas-microsoft-com:compatibility.v1">
<ms_compatibility:application xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1">
<ms_compatibility:supportedOS xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"></ms_compatibility:supportedOS>
</ms_compatibility:application>
</ms_compatibility:compatibility>
</assembly>
```
For reference, here's `cargo`'s manifest from 1.91
```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings"
xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
<activeCodePage>UTF-8</activeCodePage>
</asmv3:windowsSettings>
</asmv3:application>
<ms_compatibility:compatibility xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
xmlns="urn:schemas-microsoft-com:compatibility.v1">
<ms_compatibility:application xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1">
<ms_compatibility:supportedOS xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"></ms_compatibility:supportedOS>
</ms_compatibility:application>
</ms_compatibility:compatibility>
</assembly>
```
Closes#16877
## Test Plan
Before changes on Windows 11 25H2 (without
SeCreateSymbolicLinkPrivilege)
```console
$ uv init
$ uv add jupyterlab-widgets==3.0.16 --link-mode=symlink
...
Resolved 2 packages in [TIME]
error: Failed to install: jupyterlab_widgets-3.0.16-py3-none-any.whl (jupyterlab-widgets==3.0.16)
Caused by: failed to symlink file from [CACHE_DIR]\archive-v0\aQcqEjLJAkVwuSzohqymc\jupyterlab_widgets-3.0.16.data\data\share\jupyter\labextensions\@jupyter-widgets\jupyterlab-manager\static\packages_base_lib_index_js-webpack_sharing_consume_default_jquery_jquery.5dd13f8e980fa3c50bfe.js to [ROOT]\.venv\Lib\site-packages\jupyterlab_widgets-3.0.16.data\data\share\jupyter\labextensions\@jupyter-widgets\jupyterlab-manager\static\packages_base_lib_index_js-webpack_sharing_consume_default_jquery_jquery.5dd13f8e980fa3c50bfe.js: A required privilege is not held by the client. (os error 1314)
```
Before changes on Windows 11 25H2 (with SeCreateSymbolicLinkPrivilege)
```console
$ uv init
$ uv add jupyterlab-widgets==3.0.16 --link-mode=symlink
...
Resolved 2 packages in [TIME]
error: Failed to install: jupyterlab_widgets-3.0.16-py3-none-any.whl (jupyterlab-widgets==3.0.16)
Caused by: failed to symlink file from [CACHE_DIR]\archive-v0\aQcqEjLJAkVwuSzohqymc\jupyterlab_widgets-3.0.16.data\data\share\jupyter\labextensions\@jupyter-widgets\jupyterlab-manager\static\packages_base_lib_index_js-webpack_sharing_consume_default_jquery_jquery.5dd13f8e980fa3c50bfe.js to [ROOT]\.venv\Lib\site-packages\jupyterlab_widgets-3.0.16.data\data\share\jupyter\labextensions\@jupyter-widgets\jupyterlab-manager\static\packages_base_lib_index_js-webpack_sharing_consume_default_jquery_jquery.5dd13f8e980fa3c50bfe.js: The parameter is incorrect. (os error 87)
```
After changes on Windows 11 25H2 (with or without
SeCreateSymbolicLinkPrivilege)
```console
$ uv init
$ uv add jupyterlab-widgets==3.0.16 --link-mode=symlink
...
Resolved 2 packages in [TIME]
Installed 1 package in [TIME]
+ jupyterlab-widgets==3.0.16
```
This removes executable permissions while retaining global read / global
write.
It's been suggested we should use 0o644 instead, dropping the global
write permissions (i.e., just the owner can write), but since we're
taking an exclusive lock I don't think that would work and we'd regress
the issue that was solved by updating the permissions. I think we'll
need to revisit the locking scheme if that's the goal, but regardless,
this seems like a net improvement.
## Summary
Fix#16879 and address an additional issue where the pager prompt would
be bold regardless of NO_COLOR.
<img width="1437" height="483" alt="image"
src="https://github.com/user-attachments/assets/7234129a-364b-40c6-834a-57ac34212925"
/>
## Test Plan
Ran the test suite and manually verified against `less` 679 and `busybox` v1.34.1.
Checked with and without `NO_COLOR` on both "normal" `less`, `busybox` `less`, and `more`.
## Summary
Resolves: https://github.com/astral-sh/uv/issues/1980
Added a utility function to TestContext called
**with_git_credential_helper_blocked** that isolates the test from
accessing the credential helper value defined in global/system git
config. It does so, by writing to a file .gitconfig in the temporary
home_dir that is created as part of the TestContext.
## Test Plan
Tested it by running the test
pip_install::install_git_private_https_pat_and_username, and making sure
it doesn't affect the keyring.
## Note:
The commit hash for the uv-private-package seems to have changed.
Kindly, ensure that the modification related to that is correct.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [rustls](https://redirect.github.com/rustls/rustls) |
workspace.dependencies | patch | `0.23.29` -> `0.23.35` |
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM, only on
Monday ( * 0-3 * * 1 ) (UTC), Automerge - At any time (no schedule
defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi4xOS45IiwidXBkYXRlZEluVmVyIjoiNDIuMTkuOSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
## Summary
Fix ``uv pip install -r /dev/stdin`` which was broken in uv 0.9.12 by
https://github.com/astral-sh/uv/pull/16805 .
Example of the issue:
```
$ echo "flask" | uv pip install -r /dev/stdin
warning: Requirements file `/dev/stdin` does not contain any dependencies
Audited in 8ms
```
Note that "upstream" ``pip install`` does support `-r /dev/stdin` and
doesn't support `-r -` .
## Test Plan
2 new tests added.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [indexmap](https://redirect.github.com/indexmap-rs/indexmap) |
workspace.dependencies | patch | `2.12.0` -> `2.12.1` |
---
### Release Notes
<details>
<summary>indexmap-rs/indexmap (indexmap)</summary>
###
[`v2.12.1`](https://redirect.github.com/indexmap-rs/indexmap/blob/HEAD/RELEASES.md#2121-2025-11-20)
[Compare
Source](https://redirect.github.com/indexmap-rs/indexmap/compare/2.12.0...2.12.1)
- Simplified a lot of internals using `hashbrown`'s new bucket API.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM, only on
Monday ( * 0-3 * * 1 ) (UTC), Automerge - At any time (no schedule
defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi4xNi4xIiwidXBkYXRlZEluVmVyIjoiNDIuMTYuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [clap](https://redirect.github.com/clap-rs/clap) |
workspace.dependencies | patch | `4.5.51` -> `4.5.53` |
---
### Release Notes
<details>
<summary>clap-rs/clap (clap)</summary>
###
[`v4.5.53`](https://redirect.github.com/clap-rs/clap/blob/HEAD/CHANGELOG.md#4553---2025-11-19)
[Compare
Source](https://redirect.github.com/clap-rs/clap/compare/v4.5.52...v4.5.53)
##### Features
- Add `default_values_if`, `default_values_ifs`
###
[`v4.5.52`](https://redirect.github.com/clap-rs/clap/blob/HEAD/CHANGELOG.md#4552---2025-11-17)
[Compare
Source](https://redirect.github.com/clap-rs/clap/compare/v4.5.51...v4.5.52)
##### Fixes
- Don't panic when `args_conflicts_with_subcommands` conflicts with an
`ArgGroup`
</details>
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM, only on
Monday ( * 0-3 * * 1 ) (UTC), Automerge - At any time (no schedule
defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi4xNi4xIiwidXBkYXRlZEluVmVyIjoiNDIuMTYuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Part of https://github.com/astral-sh/uv/issues/4392
We shouldn't link to PyPI, and dropping the workspace-level
documentation link should mean that we get the auto-generated `docs.rs`
links.
Resolves https://github.com/astral-sh/uv/issues/16732
This diff treats extensionless files that contain
[PEP 723](https://peps.python.org/pep-0723/) metadata as scripts when
resolving `--with-requirements`, so inline metadata works even when the
script doesn’t end in `.py`.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Currently, it's possible for `uv export` to overwrite someones
`pyproject.toml`. This diff simply rejects project files passed in with
`-o`, so we avoid doing that.
---------
Co-authored-by: konstin <konstin@mailbox.org>
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
Small nit, but I wanted to avoid doing this access in the hot path.
(Probably not important in practice.)
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
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>
## Summary
I noticed that after first installing the free-threaded version, then
the gil version of 3.14, I wasn't able
to install greenlet, because it doesn't ship with wheels for the
free-threaded version (I think it isn't
safe for it to use that interpreter). I noticed that the change made in
3.14 wasn't updated in the docs.
## Test Plan
N/A
---------
Co-authored-by: Wade Roberts <wade.roberts@centralsquare.com>
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
#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
## Summary
This is a little goofy, but it saves us a click: when automation PRs are
opened as drafts, they don't need to be cycled through closed/opened to
force the CI to run. Instead, once undrafted the CI runs.
See #16505 for an example of the closed/opened cycle hack this avoids.
## Test Plan
No functional changes besides CI automation.
Signed-off-by: William Woodruff <william@astral.sh>
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>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [indicatif](https://redirect.github.com/console-rs/indicatif) |
workspace.dependencies | patch | `0.18.2` -> `0.18.3` |
---
### Release Notes
<details>
<summary>console-rs/indicatif (indicatif)</summary>
###
[`v0.18.3`](https://redirect.github.com/console-rs/indicatif/releases/tag/0.18.3)
[Compare
Source](https://redirect.github.com/console-rs/indicatif/compare/0.18.2...0.18.3)
#### What's Changed
- Add ProgressBar::set\_elapsed by
[@​sunshowers](https://redirect.github.com/sunshowers) in
[#​742](https://redirect.github.com/console-rs/indicatif/pull/742)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM, only on
Monday ( * 0-3 * * 1 ) (UTC), Automerge - At any time (no schedule
defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS4xNzMuMSIsInVwZGF0ZWRJblZlciI6IjQxLjE3My4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.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>
<!--
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?
-->
Related issue: none
This is a minor change; no issue is associated. Please let me know if
one is required.
## Summary
Update deprecated renovate schedule syntax
```diff
- schedule: ["before 4am on Monday"],
+ schedule: ["* 0-3 * * 1"],
```
<!-- What's the purpose of the change? What does it do, and why? -->
## Rationale
- Deprecated: Renovate plans to remove the @breejs/later library, so
cron syntax is recommended.
- Time range: at least 3-4 hours recommended for any schedule.
References:
- [Deprecated later
syntax](https://docs.renovatebot.com/key-concepts/scheduling/#deprecated-breejslater-syntax)
- [Schedule
options](https://docs.renovatebot.com/configuration-options/#schedule)
## Test Plan
<!-- How was it tested? -->
- Cron syntax verified on
[crontab.guru](https://crontab.guru/#*_0-3_*_*_1)
- Behavior in Renovate not testable directly
## 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`.
<!--
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 suggestion for uv when used with FastAPI and Docker.
## Test Plan
The Dockerfile sets `/app` as workdir, later the CMD command points
again to `app/main.py` instead of only `main.py`, causing the following
error:
```
Path does not exist app/main.py
```
## 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.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [jiff](https://redirect.github.com/BurntSushi/jiff) |
workspace.dependencies | patch | `0.2.15` -> `0.2.16` |
---
### Release Notes
<details>
<summary>BurntSushi/jiff (jiff)</summary>
###
[`v0.2.16`](https://redirect.github.com/BurntSushi/jiff/blob/HEAD/CHANGELOG.md#0216-2025-11-07)
[Compare
Source](https://redirect.github.com/BurntSushi/jiff/compare/0.2.15...0.2.16)
\===================
This release contains a number of enhancements and bug fixes that have
accrued
over the last few months. Most are small polishes. A couple of the bug
fixes
apply to panics that could occur when parsing invalid `TZ` strings or
invalid
`strptime` format strings.
Also, parsing into a `Span` should now be much faster (for both the ISO
8601
and "friendly" duration formats).
Enhancements:
- [#​298](https://redirect.github.com/BurntSushi/jiff/issues/298):
Add Serde helpers for (de)serializing `std::time::Duration` values.
- [#​396](https://redirect.github.com/BurntSushi/jiff/issues/396):
Add `Sub` and `Add` trait implementations for `Zoned` (in addition to
the
already existing trait implementations for `&Zoned`).
- [#​397](https://redirect.github.com/BurntSushi/jiff/pull/397):
Add `BrokenDownTime::set_meridiem` and ensure it overrides the hour when
formatting.
- [#​409](https://redirect.github.com/BurntSushi/jiff/pull/409):
Switch dependency on `serde` to `serde_core`. This should help speed up
compilation times in some cases.
- [#​430](https://redirect.github.com/BurntSushi/jiff/pull/430):
Add new `Zoned::series` API, making it consistent with the same API on
other
datetime types.
- [#​432](https://redirect.github.com/BurntSushi/jiff/pull/432):
When `lenient` mode is enabled for `strftime`, Jiff will no longer error
when
the formatting string contains invalid UTF-8.
- [#​432](https://redirect.github.com/BurntSushi/jiff/pull/432):
Formatting of `%y` and `%g` no longer fails based on the specific year
value.
- [#​432](https://redirect.github.com/BurntSushi/jiff/pull/432):
Parsing of `%s` is now a bit more consistent with other fields.
Moreover,
`BrokenDownTime::{to_timestamp,to_zoned}` will now prefer timestamps
parsed
with `%s` over any other fields that have been parsed.
- [#​433](https://redirect.github.com/BurntSushi/jiff/pull/433):
Allow parsing just a `%s` into a `Zoned` via the `Etc/Unknown` time
zone.
Bug fixes:
- [#​386](https://redirect.github.com/BurntSushi/jiff/issues/386):
Fix a bug where `2087-12-31T23:00:00Z` in the `Africa/Casablanca` time
zone
could not be round-tripped (because its offset was calculated
incorrectly as
a result of not handling "permanent DST" POSIX time zones).
- [#​407](https://redirect.github.com/BurntSushi/jiff/issues/407):
Fix a panic that occurred when parsing an empty string as a POSIX time
zone.
- [#​410](https://redirect.github.com/BurntSushi/jiff/issues/410):
Fix a panic that could occur when parsing `%:` via `strptime` APIs.
- [#​414](https://redirect.github.com/BurntSushi/jiff/pull/414):
Update some parts of the documentation to indicate that
`TimeZone::unknown()`
is a fallback for `TimeZone::system()` (instead of the `jiff 0.1`
behavior of
using `TimeZone::UTC`).
- [#​423](https://redirect.github.com/BurntSushi/jiff/issues/423):
Fix a panicking bug when reading malformed TZif data.
- [#​426](https://redirect.github.com/BurntSushi/jiff/issues/426):
Fix a panicking bug when parsing century (`%C`) via `strptime`.
- [#​445](https://redirect.github.com/BurntSushi/jiff/pull/445):
Fixed bugs with parsing durations like `-9223372036854775808s`
and `-PT9223372036854775808S`.
Performance:
- [#​445](https://redirect.github.com/BurntSushi/jiff/pull/445):
Parsing into `Span` or `SignedDuration` is now a fair bit faster in some
cases.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS4xNTkuNCIsInVwZGF0ZWRJblZlciI6IjQxLjE1OS40IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
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>
This is failing with
```
Run python3 scripts/check_system_python.py --uv ./uv
INFO: Checking that `pylint` isn't installed.
WARNING: Package(s) not found: pylint
INFO: Installing the package `pylint`.
DEBUG uv 0.9.7 (2cd1400fb 2025-11-06)
DEBUG Acquired shared lock for `/Users/runner/.cache/uv`
DEBUG Searching for default Python interpreter in search path or managed installations
DEBUG Found `cpython-3.14.0-macos-x86_64-none` at `/usr/local/bin/python3` (first executable in the search path)
Using Python 3.14.0 environment at: /usr/local/opt/python@3.14/Frameworks/Python.framework/Versions/3.14
DEBUG Released lock at `/Users/runner/.cache/uv/.lock`
error: The interpreter at /usr/local/opt/python@3.14/Frameworks/Python.framework/Versions/3.14 is externally managed, and indicates the following:
To install Python packages system-wide, try brew install
xyz, where xyz is the package you are trying to
install.
If you wish to install a Python library that isn't in Homebrew,
use a virtual environment:
python3 -m venv path/to/venv
source path/to/venv/bin/activate
python3 -m pip install xyz
If you wish to install a Python application that isn't in Homebrew,
it may be easiest to use 'pipx install xyz', which will manage a
virtual environment for you. You can install pipx with
brew install pipx
You may restore the old behavior of pip by passing
the '--break-system-packages' flag to pip, or by adding
'break-system-packages = true' to your pip.conf file. The latter
will permanently disable this error.
If you disable this error, we STRONGLY recommend that you additionally
pass the '--user' flag to pip, or set 'user = true' in your pip.conf
file. Failure to do this can result in a broken Homebrew installation.
Read more about this behavior here: <https://peps.python.org/pep-0668/>
```
## 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>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [tokio-util](https://tokio.rs)
([source](https://redirect.github.com/tokio-rs/tokio)) |
workspace.dependencies | patch | `0.7.15` -> `0.7.16` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>tokio-rs/tokio (tokio-util)</summary>
###
[`v0.7.16`](https://redirect.github.com/tokio-rs/tokio/compare/tokio-util-0.7.15...tokio-util-0.7.16)
[Compare
Source](https://redirect.github.com/tokio-rs/tokio/compare/tokio-util-0.7.15...tokio-util-0.7.16)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuOTEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.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"
/>
## Summary
Similar to https://github.com/astral-sh/uv/pull/8685, this adds
attestations for uv release artifacts.
The changes on this PR would add attestations for
* `dist-manifest.json`
* `uv-installer.ps1`
* `uv-installer.sh`
* All `*.tar.gz` and `*.zip` uv binary files
## Test Plan
~(clarifying note: I'm aware this file is managed cargo dist and this
will not work without allow-dirty at this time)~
~Currently cargo dist targets generation in `build_local_artifacts`
which is not used here, plus we'd ideally want to attest the GH
downloads / artifacts.~ (edit: fixed by
https://github.com/axodotdev/cargo-dist/pull/2000)
At a glance, this release workflow seems to work successfully:
e.g. Example Run:
https://github.com/samypr100/uv/actions/runs/13229100555
e.g. Example Release:
https://github.com/samypr100/uv/releases/tag/0.5.29
---------
Co-authored-by: Aria Desires <aria.desires@gmail.com>
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>
Test cases:
```
touch crates/uv-resolver/src/resolver/mod.rs && time cargo nextest run --cargo-profile dev --no-fail-fast -- --skip python_install
touch crates/uv-resolver/src/resolver/mod.rs && time cargo nextest run --cargo-profile fast-build --no-fail-fast -- --skip python_install
```
On my machine, we go from 7.x s (dev) to 8.x s (dev + opt-level 1) for
compilation, and 6.x s for the combined `fast-build` profile. With
opt-level 1, we go from 84s for the first line to 64s for the second
line.
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.
<!--
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? -->
> 4. Hyphenate compound words, e.g., use "platform-specific" not
"platform specific".
Applies to "command line arguments" -> "command-line arguments".
## 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.
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
This pull request updates the GitHub Actions workflow documentation to
use the latest version of the `actions/setup-python` action. This
ensures compatibility with recent improvements and bug fixes in the
action.
Workflow version updates:
* Updated the `uses: actions/setup-python` step from version `v5` to
`v6` in two separate workflow job examples in
`docs/guides/integration/github.md`.
[[1]](diffhunk://#diff-e864b910728c865e8e16ddb7892761fc2ef4838f2bf256eb1e20c35b24edd9fbL96-R96)
[[2]](diffhunk://#diff-e864b910728c865e8e16ddb7892761fc2ef4838f2bf256eb1e20c35b24edd9fbL119-R119)
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.
<!--
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? -->
I am a new uv user and I was reading the docs to better understand the
project scope & best practices. The section on [signal
forwarding](https://docs.astral.sh/uv/concepts/projects/run/#signal-handling)
with `uv run` caught my eye because I've used tools that use SIGHUP to
trigger config reloads or SIGUSR1/2 to enable debugging/profiling/etc so
I was a little concerned about using a runner that might block those
signals. After some searching in issues/PRs, I found that this behavior
was actually [changed earlier this
year](https://github.com/astral-sh/uv/pull/13017) to forward additional
signals (awesome!) and thought I would update the docs and save the next
person/llm from thinking their tool won't work as expected if it uses
custom signal handling.
Thanks for all your great work!
P.S. If you think it makes more sense to explicitly list all forwarded
signals as opposed to just the exclusions, I'm happy to edit.
This should avoid hitting the GitHub API to determine the latest
release, and more generally we should not automatically fetch the latest
version of Maturin in our release pipeline as it opens us to
supply-chain attacks.
## Summary
The latest version should fix our rate-limiting issues.
## Test Plan
See what happens in CI.
Signed-off-by: William Woodruff <william@astral.sh>
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
An opinionated write-up on why Python packaging needs metadata
consistency, and that we need to extend metadata to accommodate ML and
scientific users.
I didn't add a paragraph related to CUDA or accelerators in general and
wheel variants, as this is currently support neither by wheel tags nor
by PEP 508 markers, so it's not a strict metadata consistency concern,
plus this would get outdated quickly as wheel variants progress.
<!--
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
## Summary
Last time I ran the `update_schemastore.py` script in ty, due to what I
assume was a `npm` version mismatch, the `package-lock.json` file was
updated while running `npm install` in the `schemastore`. Due to the use
of `git commit -a`, it was accidentally included in the commit for the
semi-automated schemastore PR. The solution here is to only add the
actual file that we want to commit.
Same as https://github.com/astral-sh/ty/pull/1391
## Test Plan
I did a dry-run of this script (by commenting out the final `push`) and
verified that the commit did include the schema, but not the updated
`package-lock.json` file.
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>
We're regularly get questions about this. The DPO thread is the best
ressource, but it's also a long read, so I summarized some points for
uv's decision.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
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.
## Summary
Tentative PR to drop the `-rc` suffix from the published images.
Do not merge this yet until the formal release
[upstream](https://hub.docker.com/_/python) :)
## Summary
Semi related to https://github.com/astral-sh/uv/issues/15270, except
there's no removal.
Makes Alpine 3.22 and debian trixie the default tags instead of removing
bookworm and alpine 3.21 to minimize churn.
~~This PR is pending https://github.com/astral-sh/uv/pull/15351 merged
first.~~ Merged
## Test Plan
No functional changes made besides changing tag pointers.
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.
<!--
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
Corrects example command for generating pylock.toml from requirements.in
## Test Plan
Local preview
Resolves https://github.com/astral-sh/uv/issues/15665
`uv tool upgrade` already respects version pins, but when a tool was
installed with an exact version the command quietly becomes a no-op even
though users expect it to upgrade the executable. This change tweaks the
upgrade flow to detect that situation by inspecting the stored receipt
and, whenever the tool stays pinned, emit a concise hint explaining why
the version didn’t move and how to reinstall without the pin.
The message still appears if the run only refreshed supporting packages,
so users aren’t misled by dependency churn that leaves the tool itself
untouched.
I also added an integration test for the scenario end to end by
installing `babel==2.6.0`, attempting an upgrade, and asserting that the
hint is shown alongside the dependency updates.
Closes https://github.com/astral-sh/uv/issues/16112
```
❯ cargo run -q cache clean
Cache is currently in-use, waiting for other uv processes to finish (use `--force` to override)
```
Otherwise, `-v` is required to see we're waiting on a lock.
I'd rather do this than elevate the exclusive lock log message to
something more verbose because this allows us to use a more specific
message as appropriate for the situation. We also previously reduced the
verbosity of arbitrary locks, e.g., see
https://github.com/astral-sh/uv/issues/7489
<!--
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?
-->
Fixes#16131
## Summary
Fix error in example documentation for bumping version.
## Test Plan
I viewed the markdown on the branch in my fork. Looked good.
<!--
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? -->
Fixes a part of #14720
Add `TRACING_DURATIONS_FILE` to EnvironmentOptions.
## Test Plan
<!-- How was it tested? -->
## Summary
We serialize the index to the lockfile without the username, so if we
compare based on `==` and the user _includes_ the username in their
`pyproject.toml`, the check will always fail.
Closes https://github.com/astral-sh/uv/issues/16076.
Resolves https://github.com/astral-sh/uv/issues/16067
When we build the dependency graph we add an edge per `Requires-Dist`.
If a package publishes multiple marker-guarded requirements (like
pylint’s `dill>=…` for different Python versions), more than one marker
can evaluate to true at runtime, which gives us several edges pointing
to the same installed package node.
To avoid printing the package multiple times, we gather all edges
targeting that node, pass them through a `Cursor`, and aggregate their
requirement details before we print the dependency line. That
aggregation does two things:
1. If any edge carries a URL, we return that URL immediately.
2. Otherwise we merge all version specifiers into one canonical PEP 440
string.
I've added an integration test, namely `cargo test -p uv --test it
--features pypi -- no_duplicate_dependencies_with_markers` exercises the
new snapshot that installs pylint (with the real dill duplication
scenario present in the original issue) and asserts the tree output,
both with and without `--show-version-specifiers`, now shows a single
dill entry with the merged constraint.
Windows arm64 and Linux RISC-V64 are supported. Windows arm64 is special
because you can also use the x86_64 stack, which may even be a better
experience.
## Summary
I don't think it's common for this to matter, but in theory at least
it's important that these are ordered by severity. Otherwise, e.g,
changing the pre-release mode (and then returning early) could mean we
retain the forks when we otherwise shouldn't.
## Summary
This argument has always existed for compatibility, but apparently we
don't respect it. I assume it was unintentionally dropped during a
refactor.
Closes https://github.com/astral-sh/uv/issues/15950.
## Summary
Clarifies the inline annotation for the pinned
`aws-actions/configure-aws-credentials` action. Minor changes, but it's
a pleasure to contribute to a rust project !
## Test Plan
Minor doc change only. Verified by running:
cargo nextest run
cargo run python install
Coming soon: The Renovate bot (GitHub App) will be renamed to Mend. PRs
from Renovate will soon appear from 'Mend'. Learn more
[here](https://redirect.github.com/renovatebot/renovate/discussions/37842).
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [anyhow](https://redirect.github.com/dtolnay/anyhow) |
workspace.dependencies | patch | `1.0.99` -> `1.0.100` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>dtolnay/anyhow (anyhow)</summary>
###
[`v1.0.100`](https://redirect.github.com/dtolnay/anyhow/releases/tag/1.0.100)
[Compare
Source](https://redirect.github.com/dtolnay/anyhow/compare/1.0.99...1.0.100)
- Teach clippy to lint formatting arguments in `bail!`, `ensure!`,
`anyhow!`
([#​426](https://redirect.github.com/dtolnay/anyhow/issues/426))
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45Ny4xMCIsInVwZGF0ZWRJblZlciI6IjQxLjk3LjEwIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
If you provide `--refresh` to `uv lock`, we'll now always resolve (even
though it might return the same result). This is also robust to
`--locked` such that `--refresh --locked` will only fail if the lockfile
changes.
Closes https://github.com/astral-sh/uv/issues/15997.
## Summary
This PR enables users to mark a URL as an S3 endpoint, at which point uv
will sign requests to that URL by detecting credentials from the
standard AWS environment variables, configuration files, etc.
Signing is handled by the
[reqsign](https://docs.rs/reqsign/latest/reqsign/) crate, which we can
also use in the future to sign requests for other providers.
We're seeing reports of a regression from
https://github.com/astral-sh/uv/pull/15888 where `--no-cache` causes `uv
run` and `uvx` to fail to spawn a command.
The intent of this code was to allow destructive cache operations
_after_ we'd finished setting up the environment. However, it's unclear
to me that it's safe to run `uv cache clean` during a `uv run` operation
(e.g., `uv run --script` uses an environment in the cache) and, more
importantly, we cannot drop non-persistent caches (e.g., from
`--no-cache`) as they include the environment we're spawning the command
in.
Alternative to #15977 which retains release of the lock — we may want to
consider that approach still but this regression needs to be resolved
quickly.
Closes https://github.com/astral-sh/uv/issues/15989
Closes https://github.com/astral-sh/uv/issues/15987
Closes https://github.com/astral-sh/uv/issues/15967
Turns out if the minor versions matched we returned false from
`is_upgrade_of` instead of continuing to compare prerelease versions.
Closes#15955.
Note: test cases were initially generated by Claude - I tried making
them shorter.
## Test plan
```
❯ cargo run -- -v python upgrade 3.14
[...]
DEBUG Inspecting existing executable at `/Users/zsol/.local/bin/python3.14`
DEBUG Replacing existing executable for `cpython-3.14.0rc2-macos-aarch64-none` at `/Users/zsol/.local/bin/python3.14` with executable for `cpython-3.14.0rc3-macos-aarch64-none` since it is an upgrade
DEBUG Updated executable at `/Users/zsol/.local/bin/python3.14` to cpython-3.14.0rc3-macos-aarch64-none
Installed Python 3.14.0rc3 in 5.04s
+ cpython-3.14.0rc3-macos-aarch64-none (python3.14)
[...]
❯ uvx python3.14 -V
Python 3.14.0rc3
```
Coming soon: The Renovate bot (GitHub App) will be renamed to Mend. PRs
from Renovate will soon appear from 'Mend'. Learn more
[here](https://redirect.github.com/renovatebot/renovate/discussions/37842).
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[astral-sh/ruff-pre-commit](https://redirect.github.com/astral-sh/ruff-pre-commit)
| repository | patch | `v0.13.0` -> `v0.13.1` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
Note: The `pre-commit` manager in Renovate is not supported by the
`pre-commit` maintainers or community. Please do not report any problems
there, instead [create a Discussion in the Renovate
repository](https://redirect.github.com/renovatebot/renovate/discussions/new)
if you have any questions.
---
### Release Notes
<details>
<summary>astral-sh/ruff-pre-commit (astral-sh/ruff-pre-commit)</summary>
###
[`v0.13.1`](https://redirect.github.com/astral-sh/ruff-pre-commit/releases/tag/v0.13.1)
[Compare
Source](https://redirect.github.com/astral-sh/ruff-pre-commit/compare/v0.13.0...v0.13.1)
See: <https://github.com/astral-sh/ruff/releases/tag/0.13.1>
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45Ny4xMCIsInVwZGF0ZWRJblZlciI6IjQxLjk3LjEwIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Coming soon: The Renovate bot (GitHub App) will be renamed to Mend. PRs
from Renovate will soon appear from 'Mend'. Learn more
[here](https://redirect.github.com/renovatebot/renovate/discussions/37842).
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [clap](https://redirect.github.com/clap-rs/clap) |
workspace.dependencies | patch | `4.5.47` -> `4.5.48` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>clap-rs/clap (clap)</summary>
###
[`v4.5.48`](https://redirect.github.com/clap-rs/clap/blob/HEAD/CHANGELOG.md#4548---2025-09-19)
[Compare
Source](https://redirect.github.com/clap-rs/clap/compare/v4.5.47...v4.5.48)
##### Documentation
- Add a new CLI Concepts document as another way of framing clap
- Expand the `typed_derive` cookbook entry
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45Ny4xMCIsInVwZGF0ZWRJblZlciI6IjQxLjk3LjEwIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Coming soon: The Renovate bot (GitHub App) will be renamed to Mend. PRs
from Renovate will soon appear from 'Mend'. Learn more
[here](https://redirect.github.com/renovatebot/renovate/discussions/37842).
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [cargo-util](https://redirect.github.com/rust-lang/cargo) |
workspace.dependencies | patch | `0.2.22` -> `0.2.23` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45Ny4xMCIsInVwZGF0ZWRJblZlciI6IjQxLjk3LjEwIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Add an incompatibility that lets pubgrub skip of marker packages when
the base package already has an incompatible version to improve the
error messages (https://github.com/astral-sh/uv/issues/15199).
The change is also a small perf improvement. Overall this should be able
to improve performance in slow cases by avoiding trying proxy package
versions that are impossible anyway, for a (ideally very small cost) for
tracking the additional incompatibility and tracking the base package
for each proxy package.
```
$ hhyperfine --warmup 2 "uv pip compile --universal scripts/requirements/airflow.in" "target/release/uv pip compile --universal scripts/requirements/airflow.in"
Benchmark 1: uv pip compile --universal scripts/requirements/airflow.in
Time (mean ± σ): 145.5 ms ± 3.9 ms [User: 154.7 ms, System: 140.7 ms]
Range (min … max): 139.2 ms … 153.4 ms 20 runs
Benchmark 2: target/release/uv pip compile --universal scripts/requirements/airflow.in
Time (mean ± σ): 128.7 ms ± 5.5 ms [User: 141.9 ms, System: 137.3 ms]
Range (min … max): 121.8 ms … 142.0 ms 23 runs
Summary
target/release/uv pip compile --universal scripts/requirements/airflow.in ran
1.13 ± 0.06 times faster than uv pip compile --universal scripts/requirements/airflow.in
```
This implementation is the basic version: When we see a proxy
`foo{...}>=x,<y` we add a dependency edge `foo{...}>=x,<y` ->
`foo>=x,<y`. There are several way to extend this, which likely help
more with performance than with error messages.
One idea is that if we see `foo{...}>=x,<y` but we already made a
selection for `foo==z` outside that range, we can insert a dependency
`foo{...}!=z` -> `foo!=z`. This avoids trying any version of the proxy
package except the version that matches our previous selection.
Another is that if we see a dependency `foo>=x,<y`, we also add
`foo{...}>=x,y` -> `foo>=x,<y`. This allows backtracking beyond `foo`
immediately if all version of `foo{...}>=x,<y` are incompatible, since
`foo{...}>=x,<y` incompatible -> `foo>=x,<y` incompatible -> the package
that depended of `foo>=x,<y` is incompatible.
The cost for each of these operations is tracking an additional
incompatibility per virtual package. An alternative approach is to only
add the incompatibility lazily, only when we've tried several version of
the virtual package already. This needs to be weighed of with the better
error messages that the incompatibility gives, we unfortunately have
only few large reference examples.
Requires https://github.com/astral-sh/pubgrub/pull/45
Closes https://github.com/astral-sh/uv/issues/15199
Currently, `uv cache clean` and `uv cache prune` can cause crashes in
other uv processes running in parallel by removing their in-use files.
We can solve this by using a shared (read) lock on the cache directory,
while the `uv cache` operations use an exclusive (write) lock. The
drawback is that this is always one extra lock, and that we assume that
all platforms support shared locks.
Once Rust 1.89 fulfills our N-2 policy, we can add support for these
methods in fs_err and switch to
https://doc.rust-lang.org/std/fs/struct.File.html#platform-specific-behavior-2.
**Test Plan**
Open one terminal, run:
```
uv venv -c -p 3.13
UV_CACHE_DIR=cache uv cache clean
UV_CACHE_DIR=cache uv pip install numpy==2.0.0
```
Open another terminal, run:
```
UV_CACHE_DIR=cache uv cache clean
```
Fixes#15704
Part of #13883
<!--
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
I'm back again after #14041, this time for `win_arm64`. I [asked a
Windows on ARM
user](https://github.com/getlogbook/logbook/pull/451#issuecomment-3295513650)
what the value of `platform.machine()` is, and it's `ARM64`.
## Test Plan
Updated/added tests
Extends https://github.com/astral-sh/uv/pull/15679
I'm not sure if we want to do this. It is probably _generally_ true, but
I think I'd rather remove the special casing entirely? I think the main
case for this is that it could help prevent regressions from #15679 and
we can remove it in a breaking release?
Add a complete example for the most common publishing workflow, GitHub
Actions to PyPI, with screenshots for settings and a standalone
companion repo.
Closes#14398
While investigating https://github.com/astral-sh/uv/pull/15679, I
created an unnamed conda environment and noticed this quality which
allows us to detect that it's not the base environment.
## Summary
I spent time trying to figure out how to support this but came up empty.
It _seems_ like maybe the `DefaultFields` implementation in
`tracing-subscriber` uses debug formatting for fields...? So if you have
a string with ANSI codes, they end up printing as unformatted values? I
even reverted all our custom formatting in `logging.rs` and saw the same
thing.
Closes https://github.com/astral-sh/uv/issues/15840.
## Summary
Fixes issue #15190 where `uv sync --no-sources` fails to switch from
editable to registry package installations. The problem occurred because
the installer's satisfaction check didn't consider the `--no-sources`
flag when determining if an existing editable installation was
compatible with a registry requirement.
## Solution
Modified `RequirementSatisfaction::check()` to reject non-registry
installations when `SourceStrategy::Disabled` and the requirement is
from registry. Added `SourceStrategy` parameter threading through the
entire call chain from commands to the satisfaction check to ensure
consistent behavior between `uv sync --no-sources` and `uv pip install
--no-sources`.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
**Setup**
```
$ git clone https://github.com/wheelnext/variant_aarch64
$ cd variant_aarch64
$ git checkout 1d047e667dbce4c74878a68c653a6b41bc3d3684
```
**Before**
```
$ uv build -v
[...]
DEBUG Not using uv build backend direct build of , no pyproject.toml: TOML parse error at line 5, column 1
|
5 | [project]
| ^^^^^^^^^
missing field `version`
[...]
```
**After**
```
$ uv build -v
[...]
DEBUG Not using uv build backend direct build of ``, pyproject.toml does not match: The value for `build_system.build-backend` should be `"uv_build"`, not `"flit_core.buildapi"`
[...]
```
The empty string gets fixed in
https://github.com/astral-sh/uv/pull/15897
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Closes https://github.com/astral-sh/uv/issues/15604
The previous logic does not match the discussion in the original issue
about this feature, nor does it match the comment for the function. I'm
confused because I know this logic is working for some people? I'm
consequently a little wary of making this change. I'm following up with
some additional changes that should ensure this is robust, e.g., #15680
<!--
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
- Added `RemovableReason` enum to track removal context
- Updated `OnExisting::Remove` to include source information
- Modified debug message to show appropriate context
- Updated all call sites to specify correct removal source
fixes: #14734
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
This PR contains two changes: The companion PR to
https://github.com/astral-sh/packse/pull/277, which moderately
simplifies the uv side, and switching to pylock.toml for packse as
dogfooding. These changes can be applied independent from each other.
Since all files, including the vendored build dependencies, are now on
GitHub Pages under the same root, we only need a packse index root URL.
<!--
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#15485
---------
Co-authored-by: Aditya-PS-05 <adityapratapsjnhh7654@gmail.com>
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? -->
Upgrade checkout action to v5 --
https://github.com/actions/checkout/releases
## Test Plan
<!-- How was it tested? -->
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [hashbrown](https://redirect.github.com/rust-lang/hashbrown) |
workspace.dependencies | minor | `0.15.1` -> `0.16.0` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>rust-lang/hashbrown (hashbrown)</summary>
###
[`v0.16.0`](https://redirect.github.com/rust-lang/hashbrown/blob/HEAD/CHANGELOG.md#0160---2025-08-28)
[Compare
Source](https://redirect.github.com/rust-lang/hashbrown/compare/v0.15.5...v0.16.0)
##### Changed
- Bump foldhash, the default hasher, to 0.2.0.
- Replaced `DefaultHashBuilder` with a newtype wrapper around `foldhash`
instead
of re-exporting it directly.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45Ny4xMCIsInVwZGF0ZWRJblZlciI6IjQxLjk3LjEwIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: konstin <konstin@mailbox.org>
Closes https://github.com/astral-sh/uv/issues/15818
Unfortunately, this is how we perform lookups. We could also change the
lookup to include the scheme. I expect all of this to change in the
future anyway, as I want to redesign the storage model for native
credentials.
## Summary
In the process of making a different change, I noticed that we parse
this during source discovery, throw it away, then parse it again later.
## Summary
If the target for `uv pip compile` is a `pyproject.toml` in a
subdirectory, we won't have loaded the credentials when we go to lower
(since it won't be loaded as part of "configuration discovery"). We now
add those indexes just-in-time.
Closes https://github.com/astral-sh/uv/issues/15362.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[astral-sh/ruff-pre-commit](https://redirect.github.com/astral-sh/ruff-pre-commit)
| repository | minor | `v0.12.12` -> `v0.13.0` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
Note: The `pre-commit` manager in Renovate is not supported by the
`pre-commit` maintainers or community. Please do not report any problems
there, instead [create a Discussion in the Renovate
repository](https://redirect.github.com/renovatebot/renovate/discussions/new)
if you have any questions.
---
### Release Notes
<details>
<summary>astral-sh/ruff-pre-commit (astral-sh/ruff-pre-commit)</summary>
###
[`v0.13.0`](https://redirect.github.com/astral-sh/ruff-pre-commit/releases/tag/v0.13.0)
[Compare
Source](https://redirect.github.com/astral-sh/ruff-pre-commit/compare/v0.12.12...v0.13.0)
See: <https://github.com/astral-sh/ruff/releases/tag/0.13.0>
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45Ny4xMCIsInVwZGF0ZWRJblZlciI6IjQxLjk3LjEwIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
## Summary
I had to use ChatGPT to help with my research on the "correct"
architecture names for these platforms; there could still be some rough
edges, but this seems like an improvement.
Closes https://github.com/astral-sh/uv/issues/15799.
## Summary
I think this is leftover from a prior refactor whereby we used to avoid
reusing the cached environment if `--reinstall` was passed; but then we
stopped allowing `--reinstall` in `uv tool run` anyway, and this got
changed to `--refresh`. It seems wrong to skip cache reuse with
`--refresh`, though.
Closes https://github.com/astral-sh/uv/issues/15824.
## Summary
We allow space-delimiting for `--env-file`, but Clap doesn't support any
form of escaping, so as-is, there's no way to provide a `.env` file in a
directory that contains a space. We now do the splitting ourselves and
respect escapes.
Closes https://github.com/astral-sh/uv/issues/15806.
## Summary
Right now, we only list changes if the _version_ differs. This PR takes
the SHA into account. We may want to list changes to _any_ sources, but
that gets more complicated (e.g., if the user swaps the index URL, we'd
have to show _all_ changes to the index URL).
Closes#15810.
I specifically show more details than necessary in the example to make
it more clear that this is *NOT* the normal dependency-groups table.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
This PR adds a new integrations doc page for using uv with
[Coiled](https://coiled.io/). It's a slightly adapted version of this
blog post https://docs.coiled.io/blog/uv-coiled-cloud-scripts.html
Side note: it's been really pleasant using uv and Coiled together
recently
cc @zanieb for visibility
---------
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
This change extends the default initialized projects with scikit and
maturin build backends to ensure that the rust or C++ build gets invoked
when a source file changes.
## Test Plan
`cargo run init cppextension-test --build-backend=scikit` followed by
manual testing of the behaviour of the resulting project under `uv run
--with jupyter jupyter lab` and changes to the source file of the
extension.
Analogous for `cargo run init maturin-test --build-backend=maturin `.
## Relevant Issues
The question of why the python extension is not rebuilt on source
changes has been discussed in
https://github.com/astral-sh/uv/issues/15701#issuecomment-3258714942.
<!--
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
- Added `conflicts_with = "only_group"` to `--extra` arguments in
`SyncArgs`, `RunArgs`, and `ExportArgs`
- Added tests to verify proper conflict detection and error messages
**Before:** The `--extra` flag was silently ignored when used with
`--only-group`
**After:** Clear error message: `error: the argument '--only-group
<ONLY_GROUP>' cannot be used with '--extra <EXTRA>'`
fixes: #15676
## Test Plan
- Tests confirm proper error message format when `--only-group` and
`--extra` are used together
- Verified existing functionality remains unchanged when flags are used
independently
## Summary
If the user explicitly authenticated to pyx, then we attempt to use the
pyx PyTorch URLs; otherwise, we stick to `download.pytorch.org` as the
default.
## Summary
Ignore managed pre-release versions of Python for purposes of creating a
`requires-python` constraint when running `uv init --script`. This makes
the behavior consistent with `uv init` for normal projects.
## Test Plan
Added a regression test that makes sure that the constraint is
`requires-python = ">=3.13"`, even though a pre-release version of 3.14
is installed.
Consistently omit backticks after a colon in build backend messages,
following
https://github.com/astral-sh/uv/pull/15733#discussion_r2330156783.
There's still 74 matches for `: {}"` and 183 matches for `: {[^{]*}"`,
but this PR clears all matches in the build backend.
The initial motivation for this change was that we were using both the
`windows`, the `window_sys` and the `windows_core` crate in various
places. These crates have slightly unconventional versioning scheme
where there is a large workspace with the same version in general, but
only some crates get breaking releases when a new breaking release
happens, the others stay on the previous breaking version. The `windows`
crate is a shim for all three of them, with a single version. This
simplifies handling the versions.
Using `windows` over `windows_sys` has the advantage of a higher level
error interface, we now get a `Result` for all windows API calls instead
of C-style int-returns and get-last-error calls. This makes the
uv-keyring crate more resilient.
We keep using the `windows_registry` crate, which provides a higher
level interface to windows registry access.
A user in the support chat had an error message for `uv build` with the
`uv_build` backend they didn't understand, which was caused by them
having a venv in their build directory. This PR adds a dedicated error
message when adding something to a distribution that looks like a venv.
When a user passes `--no-project` argument to `uv format` command,
instead of running the formatter in the context of the current project,
run it in the context of the current directory. This is useful when the
current directory is not a project.
Closes https://github.com/astral-sh/uv/issues/15462
Paths referencing above the directory of the `pyproject.toml`, such as
`module-root = ".."`, are not supported by the build backend. The check
that should catch was not working properly, so the source distribution
built successfully and only the wheel build failed. We now error early.
The same fix is applied to data includes.
Fix#15702
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| google-github-actions/auth | action | digest | `b7593ed` -> `fc21748`
|
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuOTEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [mimalloc](https://redirect.github.com/purpleprotocol/mimalloc_rust) |
dependencies | patch | `0.1.47` -> `0.1.48` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>purpleprotocol/mimalloc_rust (mimalloc)</summary>
###
[`v0.1.48`](https://redirect.github.com/purpleprotocol/mimalloc_rust/releases/tag/v0.1.48):
Version 0.1.48
[Compare
Source](https://redirect.github.com/purpleprotocol/mimalloc_rust/compare/v0.1.47...v0.1.48)
##### Changes
- Mimalloc `v3` feature flag. (credits
[@​gschulze](https://redirect.github.com/gschulze)).
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuOTEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| google-github-actions/setup-gcloud | action | digest | `26f734c` ->
`aa5489c` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuOTEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
## Summary
We support `--no-editable` on the CLI, but now that workspace members
and path dependencies can be marked as `editable = false`, I think it
makes sense for `--editable` to override that.
## 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.
<!--
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 adds support for building loongarch64 binaries in CI. As uv
itself runs perfectly well on loongarch64 and with the latter's userbase
steadily growing, it would be a good idea to ship prebuilt binaries to
help them out.
Please note that as Ubuntu is not yet available for loongarch64, I have
elected to use a Debian Trixie container maintained by community
members. In addition, as Debian's pip does not allow installing modules
system-wide, the workflow for loongarch64 installs additional modules in
a virtual environment.
## Test Plan
<!-- How was it tested? -->
Tests are included in CI and the loongarch64 artifacts built in [this
workflow](https://github.com/SkyBird233/uv/actions/runs/17091637376/job/48466486690)
has been smoke tested.
## Summary
This refreshes the venv activation scripts from upstream `virtualenv`
project.
This was largely triggered by a problem in the activate.nu script (for
nushell):
- #14888
- #14914
- #14917
I was careful to respect the git history going back to astral-sh/uv#3376
(the last time this was done).
Actually I looked at the complete history from back when this
`uv-virtualenv` crate was named after a Pokémon (⁉️), but I found
nothing (about activation scripts) from back then that hasn't been
overwritten since.
### Some post-processing was involved
- Retained license info at top of scripts
- Retained template vars (eg `{{ BIN_PATH }}`) to assure current support
toward relocatable venv
- Retained deviation from upstream in astral-sh/uv#5640. This seems to
be the only deviation that isn't in sync with upstream.
### Notable changes from upstream
- (omitted due to undesirable complexity) pypa/virtualenv#2928 and its
follow-up pypa/virtualenv#2940
- pypa/virtualenv#2910 (what prompted astral-sh/uv#14917 from
astral-sh/uv#14888)
## Test Plan
There was a request in #14917 to add unit tests to detect breakage or
errors.
I have added a CI job that runs the nushell activation script.
But I think it is better to have the CI test all/most supported shells.
See also #15294
I have tested this locally using
- [x] nushell (v0.106.1)
- [x] cmd.exe (Microsoft Windows [Version 10.0.26100.4946])
- [x] bash in WSL (GNU bash, version 5.1.16(1)-release
(x86_64-pc-linux-gnu))
- [x] pwsh (PSVersion 5.1.26100.4768)
uv currently panics with a stack overflow when requirements or
constraints are recursively included. Instead, we ignore files we have
already seen. The one complexity here is that we have to track whether
we're in a requirements inclusion or in a constraints inclusion, to
allow including a file separately for requirements and for constraints,
and to handle `-r` inside or `-c` (which we treat as constraints too).
Fixes#15650
<!--
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
Closes#15586
## Summary
If the package that has the `match-runtime` dependency itself isn't
being installed, we should avoid erroring if the package it _depends on_
isn't in the resolution.
Closes https://github.com/astral-sh/uv/issues/15661.
<!--
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 adds instructions to install a C compiler on Fedora-based Linux
distributions.
## Test Plan
```
# Start Fedora container interactively (can probably be done on Docker as well)
podman run -it registry.fedoraproject.org/fedora
# From now on, run all commands inside the container.
# Install Rustup
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# Add cargo bin folder to PATH
export PATH="${HOME}/.cargo/bin:${PATH}"
# Install git, clone uv project and get into its folder
dnf install git
git clone https://github.com/astral-sh/uv.git
cd uv
# Try to compile uv and fail (error: linker `cc` not found)
cargo build
# Install C compiler
dnf install gcc
# Try to compile uv again. This time, successfully.
cargo build
```
Signed-off-by: Mateus Devino <mdevino@ibm.com>
## 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.
## Summary
This PR allows pyx to send down hashes for zstandard-compressed
tarballs. If the hash is present, then the file is assumed to be present
at `${wheel_url}.tar.zst`, similar in design to PEP 658
`${wheel_metadata}.metadata` files. The intent here is that the index
must include the wheel (to support all clients and support
random-access), but can optionally include a zstandard-compressed
version alongside it.
## Summary
`uv publish --dry-run` will perform the `--check-url` validation, and
hit the `/validate` endpoint if the registry is known to support
fast-path validation (like pyx). The `/validate` endpoint lets us
validate an upload without uploading the file _contents_, which lets you
skip the expensive step for common mistakes.
In the future, my hope is that the `/validate` step will deprecated in
favor of Upload API 2.0.
## Summary
This PR adds support for the `application/vnd.pyx.simple.v1` content
type, similar to `application/vnd.pypi.simple.v1` with the exception
that it can also include core metadata for package-versions directly.
## Summary
This PR adds support for pyx to `uv auth login`, `uv auth logout`, and
`uv auth token`. These are generic uv commands that can be used to store
credentials for arbitrary indexes and other URLs, but we include a
fast-path for pyx that initiates the appropriate login or logout flow.
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.
Adds locking of the credentials store for concurrency safety. It's
important to hold the lock from read -> write so credentials are not
dropped during concurrent writes.
I opted not to attach the lock to the store itself. Instead, I return
the lock on read and require it on write to encourage safe use. Maybe
attaching the source path to the store struct and adding a `lock(&self)`
method would make sense? but then you can forget to take the lock at the
right time. The main problem with the interface here is to write a _new_
store you have to take the lock yourself, and you could make a mistake
by taking a lock for the wrong path or something. The fix for that would
be to introduce a new `CredentialStoreHandle` type or something, but
that seems overzealous rn. We also don't eagerly drop the lock on token
read, although we could.
Adds a default plain text storage mechanism to `uv auth`.
While we'd prefer to use the system store, the "native" keyring support
is experimental still and I don't want to ship an unusable interface.
@geofft also suggested that the story for secure credential storage is
much weaker on Linux than macOS and Windows and felt this approach would
be needed regardless.
We'll switch over to using the native keyring by default in the future.
On Linux, we can now fallback to a plaintext store the secret store is
not configured, which is a nice property.
Right now, we store credentials in a TOML file in the uv state
directory. I expect to also read from the uv config directory in the
future, but we don't need it immediately.
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
Override `sys.base_prefix` when performing `python_module` tests, in
order to prevent `find_uv_bin()` from finding `uv` installed alongside
system Python, and therefore fix test failures on Gentoo.
Fixes#15368
## Test Plan
```
cargo test --profile=fast-build --features git --features pypi --features python --no-default-features --test it python_module
```
Signed-off-by: Michał Górny <mgorny@gentoo.org>
When migrating from the `reqwest_retry` crate, we want to ensure that
the status codes we retry stay the same. This also helps us to
intentionally migrate to a different list later, by enumerating the list
of status codes that are retried.
In https://github.com/astral-sh/uv/issues/11636, we're getting reports
for installation flakes that report an invalid package format for what
appears to be a network problem. Since we're cutting the error reporting
to the first error message in the chain, we're not reporting the actual
network error underneath it.
This PR displays the whole error chain for invalid package format
errors, so we can debug and eventually catch-and-retry
https://github.com/astral-sh/uv/issues/11636.
## 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.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| aws-actions/configure-aws-credentials | action | digest | `a159d7b` ->
`c5a43c3` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS40MC4wIiwidXBkYXRlZEluVmVyIjoiNDEuODIuNyIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
When there is an error during the streaming download and unpack for
Python interpreter and bin installs, we would previously fail, causing a
lot of CI flakes on GitHub Actions.
The problem was that the error is not one of the extended IO errors we
were previously handling, but a regular reqwest error, nested below
layers of errors of other crates processing the stream, including some
IO errors. We now handle nested reqwest errors, too.
This surfaced another problem: Our manual retry loop couldn't inform the
retry middleware that it already performed the limit of retries, and
that the middleware should not retry anymore. While too many retries are
more a problem for debugging than for the user, this causes confusing
error output. To work around this, we disable the retries in the client
and handle all retry errors in our loop.
Fixes https://github.com/astral-sh/uv/issues/14171
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Alternative to #15105
Instead of building a `BaseClientBuilder` from `NetworkSettings` each
time we need a client, we instead build a single `BaseClientBuilder` and
pass it around. The `RegistryClientBuilder` then uses
`BaseClientBuilder` exclusively for configuration. This removes a chunk
of copy-and-paste code, and also moves the fallible `retries_from_env`
into a single place
Borrow vs. clone is mostly ad-hoc, we can change it in either direction
if it matters.
Closes#15105
https://github.com/astral-sh/uv/issues/11836#issuecomment-3022735011 was
caused by a missing `cache_index_credentials()` call. This call was
always preceding a registry client builder. We can improve this
situation by caching index credentials in the registry client builder.
<!--
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
Adds the enhancement proposed in #15470. Each package in the dependency
tree now shows its compressed wheel file size, reading the wheel sizes
directly from the lockfile (uv.lock). Doesn't break existing tree
formatting or options. If no wheel size is available, nothing is added.
Now, developers can identify large packages in their dependency tree.
The tree still shows extras exactly as before, and then appends a size
for the package.
## Test Plan
Manually tested :
```
harsh@fcr-node:~/uv/test-uv-tree-sizes$ ../target/debug/uv tree
Using CPython 3.13.7
warning: No `requires-python` value found in the workspace. Defaulting to `>=3.13`.
Resolved 4 packages in 6ms
pure-python v0.1.0
├── click v8.2.1
└── six v1.17.0
harsh@fcr-node:~/uv/test-uv-tree-sizes$ ../target/debug/uv tree --show-sizes
Using CPython 3.13.7
warning: No `requires-python` value found in the workspace. Defaulting to `>=3.13`.
Resolved 4 packages in 6ms
pure-python v0.1.0
├── click v8.2.1 (99.8KiB)
└── six v1.17.0 (10.8KiB)
```
## Summary
`CLICOLOR_FORCE` changes the output of underlying build commands, which
messes with wrapper tools trying to parse their output.
Closes#12564, closes#15415.
Add support for `RUST_LOG` to the uv build backend. While we were
previously using logging statements in the uv build backend, they could
only be shown when when using the direct build fast path through uv, as
there was no tracing subscriber to write log messages out. This means no
debug logging when using the build backend through pip, `python -m
build`, an incompatible version of uv, or any other build frontend; No
option to figure why includes and excludes behave the way they do.
This PR closes this gap by adding a tracing subscriber. The only option
to enable it is `RUST_LOG`, as we don't have a CLI. The formatting style
is the same as for uv, and color is also support in the same way, albeit
only through anstream's support for TTYs and environment variables. We
recommend only `RUST_LOG=uv=debug` and `RUST_LOG=uv=verbose` in the
docs, but this can be used to debug into crates such as `glob`, too.
<img width="1008" height="325" alt="image"
src="https://github.com/user-attachments/assets/d33df219-750b-46a2-b3b4-8895aa137ab9"
/>
**Before**
```
$ pip wheel . -v [...]
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/scripts/packages/built-by-uv
Running command pip subprocess to install build dependencies
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/target/wheels/uv_build-0.8.13-py3-none-manylinux_2_39_x86_64.whl
Installing collected packages: uv_build
Successfully installed uv_build-0.8.13
Installing build dependencies ... done
Running command Getting requirements to build wheel
Getting requirements to build wheel ... done
Running command Preparing metadata (pyproject.toml)
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: built-by-uv
Running command Building wheel for built-by-uv (pyproject.toml)
Error: Unsupported glob expression in: `tool.uv.build-backend.*-exclude`
Caused by:
Invalid character `!` at position 10 in glob: `**/build-*!$§%!½¼²¼³¬!§%$§%.h`. hint: Characters can be escaped with a backslash
error: subprocess-exited-with-error
× Building wheel for built-by-uv (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
full command: /usr/bin/python3 /usr/lib/python3/dist-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /tmp/tmpow1illc9
cwd: /home/konsti/projects/uv/scripts/packages/built-by-uv
Building wheel for built-by-uv (pyproject.toml) ... error
ERROR: Failed building wheel for built-by-uv
Failed to build built-by-uv
ERROR: Failed to build one or more wheels
```
**After**
```
$ RUST_LOG=uv=debug pip wheel . -v [...]
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/scripts/packages/built-by-uv
Running command pip subprocess to install build dependencies
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/target/wheels/uv_build-0.8.13-py3-none-manylinux_2_39_x86_64.whl
Installing collected packages: uv_build
Successfully installed uv_build-0.8.13
Installing build dependencies ... done
Running command Getting requirements to build wheel
Getting requirements to build wheel ... done
Running command Preparing metadata (pyproject.toml)
DEBUG Writing metadata files to /tmp/pip-modern-metadata-l_kh78cj
DEBUG Found PEP 639 license declarations, using METADATA 2.4
DEBUG License files match: `LICENSE-APACHE`
DEBUG License files match: `LICENSE-MIT`
DEBUG License files match: `third-party-licenses/PEP-401.txt`
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: built-by-uv
Running command Building wheel for built-by-uv (pyproject.toml)
DEBUG Checking metadata directory /tmp/pip-modern-metadata-l_kh78cj/built_by_uv-0.1.0.dist-info
DEBUG Found PEP 639 license declarations, using METADATA 2.4
DEBUG License files match: `LICENSE-APACHE`
DEBUG License files match: `LICENSE-MIT`
DEBUG License files match: `third-party-licenses/PEP-401.txt`
DEBUG Writing wheel at /tmp/pip-wheel-bu6to9i7/built_by_uv-0.1.0-py3-none-any.whl
DEBUG Wheel excludes: ["__pycache__", "*.pyc", "*.pyo", "build-*!$§%!½¼²¼³¬!§%$§%.h", "/src/built_by_uv/not-packaged.txt"]
Error: Unsupported glob expression in: `tool.uv.build-backend.*-exclude`
Caused by:
Invalid character `!` at position 10 in glob: `**/build-*!$§%!½¼²¼³¬!§%$§%.h`. hint: Characters can be escaped with a backslash
error: subprocess-exited-with-error
× Building wheel for built-by-uv (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
full command: /usr/bin/python3 /usr/lib/python3/dist-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /tmp/tmpjrxou13a
cwd: /home/konsti/projects/uv/scripts/packages/built-by-uv
Building wheel for built-by-uv (pyproject.toml) ... error
ERROR: Failed building wheel for built-by-uv
Failed to build built-by-uv
ERROR: Failed to build one or more wheels
```
(There is no color in the above uv log statements, as pip doesn't
register as a TTY)
Fixes#12723
<!--
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
Update to the docs
## Test Plan
CI
The Renovate config in this repository needs migrating. Typically this
is because one or more configuration options you are using have been
renamed.
You don't need to merge this PR right away, because Renovate will
continue to migrate these fields internally each time it runs. But later
some of these fields may be fully deprecated and the migrations removed.
So it's a good idea to merge this migration PR soon.
#### [PLEASE
NOTE](https://docs.renovatebot.com/configuration-options#configmigration):
JSON5 config file migrated! All comments & trailing commas were removed.
🔕 **Ignore**: Close this PR and you won't be reminded about config
migration again, but one day your current config may no longer be valid.
❓ Got questions? Does something look wrong to you? Please don't hesitate
to [request help
here](https://redirect.github.com/renovatebot/renovate/discussions).
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: konstin <konstin@mailbox.org>
The Renovate config in this repository needs migrating. Typically this
is because one or more configuration options you are using have been
renamed.
You don't need to merge this PR right away, because Renovate will
continue to migrate these fields internally each time it runs. But later
some of these fields may be fully deprecated and the migrations removed.
So it's a good idea to merge this migration PR soon.
#### [PLEASE
NOTE](https://docs.renovatebot.com/configuration-options#configmigration):
JSON5 config file migrated! All comments & trailing commas were removed.
🔕 **Ignore**: Close this PR and you won't be reminded about config
migration again, but one day your current config may no longer be valid.
❓ Got questions? Does something look wrong to you? Please don't hesitate
to [request help
here](https://redirect.github.com/renovatebot/renovate/discussions).
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: konstin <konstin@mailbox.org>
Allows pinning the Python build version via environment variables, e.g.,
`UV_PYTHON_CPYTHON_BUILD=...`. Each variable is implementation specific,
because they use different versioning schemes.
Updates the Python download metadata to include a `build` string, so we
can filter downloads by the pin. Writes the build version to a file in
the managed install, e.g., `cpython-3.10.18-macos-aarch64-none/BUILD`,
so we can filter installed versions by the pin.
Some important follow-up here:
- Include the build version in not found errors (when pinned)
- Automatically use a remote list of Python downloads to satisfy build
versions not present in the latest embedded download metadata
Some less important follow-ups to consider:
- Allow using ranges for build version pins
## Summary
We've received several requests to validate that installed wheels match
the current Python platform. This isn't _super_ common, since it
requires that your platform changes in some meaningful way (e.g., you
switch from x86 to ARM), though in practice, it sounds like it _can_
happen in HPC environments. This seems like a good thing to do
regardless, so we now validate that the tags (as recoded in `WHEEL`) are
consistent with the current platform during installs.
Closes https://github.com/astral-sh/uv/issues/15035.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| google-github-actions/setup-gcloud | action | digest | `cb1e50a` ->
`26f734c` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS44Mi43IiwidXBkYXRlZEluVmVyIjoiNDEuODIuNyIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [serde-untagged](https://redirect.github.com/dtolnay/serde-untagged) |
workspace.dependencies | patch | `0.1.7` -> `0.1.8` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>dtolnay/serde-untagged (serde-untagged)</summary>
###
[`v0.1.8`](https://redirect.github.com/dtolnay/serde-untagged/releases/tag/0.1.8)
[Compare
Source](https://redirect.github.com/dtolnay/serde-untagged/compare/0.1.7...0.1.8)
- Add support for `visit_none`
([#​10](https://redirect.github.com/dtolnay/serde-untagged/issues/10),
thanks [@​epage](https://redirect.github.com/epage))
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS44Mi43IiwidXBkYXRlZEluVmVyIjoiNDEuODIuNyIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [tokio](https://tokio.rs)
([source](https://redirect.github.com/tokio-rs/tokio)) |
workspace.dependencies | patch | `1.47.0` -> `1.47.1` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>tokio-rs/tokio (tokio)</summary>
###
[`v1.47.1`](https://redirect.github.com/tokio-rs/tokio/releases/tag/tokio-1.47.1):
Tokio v1.47.1
[Compare
Source](https://redirect.github.com/tokio-rs/tokio/compare/tokio-1.47.0...tokio-1.47.1)
### 1.47.1 (August 1st, 2025)
##### Fixed
- process: fix panic from spurious pidfd wakeup ([#​7494])
- sync: fix broken link of Python `asyncio.Event` in `SetOnce` docs
([#​7485])
[#​7485]: https://redirect.github.com/tokio-rs/tokio/pull/7485
[#​7494]: https://redirect.github.com/tokio-rs/tokio/pull/7494
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS44Mi43IiwidXBkYXRlZEluVmVyIjoiNDEuODIuNyIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
## Summary
After chatting with the PyTorch team, it looks like some number of
wheels were accidentally uploaded with
`no-cache,no-store,must-revalidate` due to
https://github.com/pytorch/pytorch/pull/149218. They're going to correct
this for the respective wheels. I've encouraged them to set an immutable
caching header for these files, and it might happen. But even if this
isn't set, by default we only allow these wheels to be cached for 600s,
since the other wheels don't include a `Cache-Control` header at all
(but do include a `Last-Modified`, so we cache based on our heuristic:
`Freshness lifetime heuristically assumed because of presence of
last-modified header: 600s`). This probably leads to tons of unnecessary
downloads for users over time. Andrey from the PyTorch team agreed that
we should do this.
Closes https://github.com/astral-sh/uv/issues/15480.
## Summary
This is causing some cyclic dependencies issues for me, because these
can be used in virtually _any_ crate (like `uv-install-wheel`), which
then means that all of `uv-configuration` becomes a dependency, etc. I
think this should be a leaf crate so that we can safely depend on it
anywhere.
## Summary
Move the Resolver reference into a new Internals section in the
reference. Add the new nav item, fix internal linking to the new path,
fix server side redirect to the new path for external traffic via
redirect_maps, fix non existent anchor in
"docs/concepts/projects/dependencies.md"
Closes#15412
<!--
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? -->
Closes#14866. Adds a `no-install-local` flag to the sync and export
commands that excludes locally defined packages from being installed.
This helps with if you're caching your virtual environment. You can
exclude local packages since they're more likely to change between
builds.
## Test Plan
snapshot test: `sync::no_install_local`
CI
## Notes
I made an `InstallOptions` struct to avoid a crate isolation issue I was
running into while implementing.
Thanks for maintaining this project!
<!--
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
i noticed some of the line highlights are wrong in the docs
## Test Plan
visual verification
## Summary
There isn't any risk here, and we have reports of at least one zip file
with more than one (but fewer than, e.g., 10) null bytes.
Closes https://github.com/astral-sh/uv/issues/15451.
## 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>
<!--
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
Updates libc dependencies to fix#15128
Note: The whole build on AIX still doesn't work but libc works now.
## Test Plan
<!-- How was it tested? -->
Build on AIX 7300-03-00-2446:
```
bash-5.2$ cargo build --offline
Compiling proc-macro2 v1.0.95
Compiling unicode-ident v1.0.18
Compiling libc v0.2.175 # worked
Compiling cfg-if v1.0.1
Compiling memchr v2.7.5
Compiling serde v1.0.219
Compiling pin-project-lite v0.2.16
Compiling shlex v1.3.0
Compiling itoa v1.0.15
Compiling once_cell v1.21.3
Compiling smallvec v1.15.1
Compiling bytes v1.10.1
Compiling stable_deref_trait v1.2.0
Compiling ryu v1.0.20
Compiling tracing-core v0.1.34
Compiling bitflags v2.9.1
Compiling foldhash v0.1.5
Compiling allocator-api2 v0.2.21
Compiling equivalent v1.0.2
Compiling litemap v0.8.0
Compiling quote v1.0.40
Compiling jobserver v0.1.33 # worked too (depends on libc)
Compiling hashbrown v0.15.5
Compiling syn v2.0.104
Compiling serde_json v1.0.142
Compiling cc v1.2.30
Compiling autocfg v1.5.0
Compiling writeable v0.6.1
Compiling signal-hook-registry v1.4.5
Compiling mio v1.0.4
Compiling socket2 v0.6.0
Compiling icu_normalizer_data v2.0.0
Compiling icu_properties_data v2.0.1
Compiling percent-encoding v2.3.1
Compiling form_urlencoded v1.2.1
[...]
```
Co-authored-by: Richter, Michael (G-GP-A/4) <michael.richter@vwgis.de>
## Summary
Follow up to
https://github.com/astral-sh/uv/pull/15269#issuecomment-3194000772
Enables the following additional images to be published
* buildpack-deps:trixie
* debian:trixie-slim
* alpine:3.22
## Test Plan
Existing Tests. The newly added images were checked manually.
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
```
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [async-trait](https://redirect.github.com/dtolnay/async-trait) |
workspace.dependencies | patch | `0.1.88` -> `0.1.89` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>dtolnay/async-trait (async-trait)</summary>
###
[`v0.1.89`](https://redirect.github.com/dtolnay/async-trait/releases/tag/0.1.89)
[Compare
Source](https://redirect.github.com/dtolnay/async-trait/compare/0.1.88...0.1.89)
- Improve IDE functionality
([#​293](https://redirect.github.com/dtolnay/async-trait/issues/293),
thanks [@​Veykril](https://redirect.github.com/Veykril))
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS43MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNzEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [anyhow](https://redirect.github.com/dtolnay/anyhow) |
workspace.dependencies | patch | `1.0.98` -> `1.0.99` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>dtolnay/anyhow (anyhow)</summary>
###
[`v1.0.99`](https://redirect.github.com/dtolnay/anyhow/releases/tag/1.0.99)
[Compare
Source](https://redirect.github.com/dtolnay/anyhow/compare/1.0.98...1.0.99)
- Allow build-script cleanup failure with NFSv3 output directory to be
non-fatal
([#​420](https://redirect.github.com/dtolnay/anyhow/issues/420))
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS43MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNzEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[EmbarkStudios/cargo-deny-action](https://redirect.github.com/EmbarkStudios/cargo-deny-action)
| action | patch | `v2.0.12` -> `v2.0.13` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>EmbarkStudios/cargo-deny-action
(EmbarkStudios/cargo-deny-action)</summary>
###
[`v2.0.13`](https://redirect.github.com/EmbarkStudios/cargo-deny-action/releases/tag/v2.0.13):
Release 2.0.13 - cargo-deny 0.18.4
[Compare
Source](https://redirect.github.com/EmbarkStudios/cargo-deny-action/compare/v2.0.12...v2.0.13)
##### Added
-
[PR#779](https://redirect.github.com/EmbarkStudios/cargo-deny/pull/779)
added the `--metadata-path` argument to use a cargo metadata JSON file
instead of calling cargo metadata, resolving
[#​777](https://redirect.github.com/EmbarkStudios/cargo-deny/issues/777).
-
[PR#782](https://redirect.github.com/EmbarkStudios/cargo-deny/pull/782)
added `sources.unused-allow-source` to allow configuration of the lint
level when a source is allowed but not used by any crate in the graph,
closing
[#​781](https://redirect.github.com/EmbarkStudios/cargo-deny/issues/781).
##### Changed
-
[PR#786](https://redirect.github.com/EmbarkStudios/cargo-deny/pull/786)
changed the license check output. `/` is no longer corrected to `OR`,
and if the license expression is found in the package's manifest, that
span is used in diagnostic messages instead of the synthesized manifest.
##### Fixed
-
[PR#786](https://redirect.github.com/EmbarkStudios/cargo-deny/pull/786)
resolved
[#​784](https://redirect.github.com/EmbarkStudios/cargo-deny/issues/784)
by updating `spdx` to a new version that forces all GNU licenses to be
exactly equal when comparing license expressions to licensee
expressions, which is incredibly pedantic, but means the license
comparison is entirely in the hands of the user so that I no longer have
to deal with GNU licenses.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS43MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNzEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[depot/build-push-action](https://redirect.github.com/depot/build-push-action)
| action | patch | `v1.16.1` -> `v1.16.2` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>depot/build-push-action (depot/build-push-action)</summary>
###
[`v1.16.2`](https://redirect.github.com/depot/build-push-action/releases/tag/v1.16.2)
[Compare
Source](https://redirect.github.com/depot/build-push-action/compare/v1.16.1...v1.16.2)
##### What's Changed
- Use ubuntu-latest for release workflow
([#​42](https://redirect.github.com/depot/build-push-action/issues/42))
[@​jacobwgillespie](https://redirect.github.com/jacobwgillespie)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS43MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNzEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
## 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).
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[depot/build-push-action](https://redirect.github.com/depot/build-push-action)
| action | patch | `v1.16.0` -> `v1.16.1` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>depot/build-push-action (depot/build-push-action)</summary>
###
[`v1.16.1`](https://redirect.github.com/depot/build-push-action/releases/tag/v1.16.1)
[Compare
Source](https://redirect.github.com/depot/build-push-action/compare/v1.16.0...v1.16.1)
##### What's Changed
- Update
[@​depot/actions-public-oidc-client](https://redirect.github.com/depot/actions-public-oidc-client)
to v1.1.0
([#​41](https://redirect.github.com/depot/build-push-action/issues/41))
[@​jacobwgillespie](https://redirect.github.com/jacobwgillespie)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS43MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNzEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
## Summary
I noticed that these paths aren't returning the cache information, so if
you install through these paths, we actually don't write `uv_cache.json`
at all. I'm not sure how a user would actually end up here, because
assuming there are no bugs, we don't really ever use this path? The
install plan indexes the cached wheels and marks the wheel as installed,
which means it's typically a mistake if we're asking the
`DistributionDatabase` for a wheel that's already available in the
cache... But I did verify that if I _skip_ the install plan's cache
lookup, we write a wheel without `uv_cache.json`, so this is definitely
more correct.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[depot/build-push-action](https://redirect.github.com/depot/build-push-action)
| action | minor | `v1.15.0` -> `v1.16.0` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>depot/build-push-action (depot/build-push-action)</summary>
###
[`v1.16.0`](https://redirect.github.com/depot/build-push-action/releases/tag/v1.16.0)
[Compare
Source](https://redirect.github.com/depot/build-push-action/compare/v1.15.0...v1.16.0)
##### What's Changed
- Add support for annotations
([#​38](https://redirect.github.com/depot/build-push-action/issues/38))
[@​zanieb](https://redirect.github.com/zanieb)
- feat: add `save-tags` for multiple depot registry tags
([#​40](https://redirect.github.com/depot/build-push-action/issues/40))
[@​goller](https://redirect.github.com/goller)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS42Ni4yIiwidXBkYXRlZEluVmVyIjoiNDEuNjYuMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This allows `PythonDownloadRequest` which is used for parsing general
install key requests to have missing segments, which unblocks requests
like `windows-aarch64` or `cpython-linux` (whereas before those would
require `any-any-windows-aarch64` and `cpython-any-linux` respectively).
We still require strict ordering of segments.
Previously, we only allowed missing segments at the end of the key.
This uses a state machine for parsing, which is quite a bit more
complicated.
I'm a little hesitant about the possibility that this regresses error
messages and the complexity of the implementation, but `uv run -p
aarch64` seems valuable following #13724. The alternative to this would
probably be to make these explicit in various places? e.g., expose
`--python-arch`, `--python-libc`, and `--python-os`? Or make
`--python-platform` (which already exists) accept a subset of the keys?
There is a possibility of regressions here, e.g., if something matches
this parser it will not fallback to the `PythonRequest::ExecutableName`
case and we've made this parser more permissive, but I think that should
be quite rare?
## Summary
Split the cleanup fixes from https://github.com/astral-sh/uv/pull/15196
into a separate PR for easier review.
This cleans up some minor env var usage / references throughout tests
and runtime code.
## Test Plan
Existing Tests. No functional changes.
## Summary
This re-creates #15145, with fixes following the revert in #15174.
The overall approach is the same, except that I've added an explicit
permissions block to `docker-annotate-base` that should cover the needed
permissions in that job.
(One confusion is around how that wasn't failing before -- FWICT it was
receiving the default `GITHUB_TOKEN`, which doesn't include `id-token:
write` or `packages: write`. So it _should_ have been failing even
before I explicitly did `permissions: {}`...)
Edit: Oh, I see why -- the actual release process does a
`workflow_call`, so this inherits its `GITHUB_TOKEN` from
`release.yml:custom-build-docker`, which in turn has the right
permissions granted to it.
## Test Plan
See what happens in CI. Plus maybe we could do a release dry-run?
Signed-off-by: William Woodruff <william@astral.sh>
## 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.
## Summary
fixes https://github.com/astral-sh/uv/issues/15172
This change adds a regex filter to normalize dates in GitHub release
URLs within the `python_install_no_cache` test snapshot.
**Problem:**
The test was hardcoding the date `20250808` in the expected error
message URL:
```console
https://github.com/astral-sh/python-build-standalone/releases/download/20250808/cpython-3.12.[PATCH]-[DATE]-[PLATFORM].tar.gz
```
This creates a maintenance burden as the snapshot would need to be
updated whenever the underlying Python release date changes.
**Solution:**
Added a regex filter `r"releases/download/\d{8}/"` →
`"releases/download/[DATE]/"` to replace any 8-digit date in the GitHub
release URL path with a generic `[DATE]` placeholder.
**Result:**
The test is now resilient to new Python releases and won't require
snapshot updates when the underlying release date changes. The error
message now consistently shows:
```console
https://github.com/astral-sh/python-build-standalone/releases/download/[DATE]/cpython-3.12.[PATCH]-[DATE]-[PLATFORM].tar.gz
```
## Test Plan
`python_install` tests seem to pass ✅
```console
$ cargo test --package uv --test it -- python_install
Compiling uv-cli v0.0.1 (/home/ubaid/projects/uv/crates/uv-cli)
Compiling uv v0.8.8 (/home/ubaid/projects/uv/crates/uv)
Finished `test` profile [unoptimized + debuginfo] target(s) in 19.04s
Running tests/it/main.rs (target/debug/deps/it-14d47eb0324a8a0a)
running 30 tests
test python_install::python_install_unknown ... ok
test network::python_install_io_error ... ok
test network::python_install_http_500 ... ok
test python_install::python_install_invalid_request ... ok
test python_install::python_install_broken_link ... ok
test python_install::python_install_preview_no_bin ... ok
test python_install::regression_cpython ... ok
test python_install::uninstall_last_patch ... ok
test python_install::install_no_transparent_upgrade_with_venv_patch_specification ... ok
test python_install::install_lower_patch_automatically ... ok
test python_install::uninstall_highest_patch ... ok
test python_install::install_transparent_patch_upgrade_venv_module ... ok
test python_install::python_install_default_from_env ... ok
test python_install::python_install ... ok
test python_install::python_reinstall_patch ... ok
test python_install::python_install_force ... ok
test python_install::install_transparent_patch_upgrade_uv_venv ... ok
test python_install::install_multiple_patches ... ok
test python_install::python_install_314 ... ok
test python_install::python_install_default ... ok
test python_install::python_install_automatic ... ok
test python_install::python_install_freethreaded ... ok
test python_install::python_install_preview_upgrade ... ok
test python_install::python_install_no_cache ... ok
test python_install::python_install_default_preview ... ok
test python_install::python_install_preview ... ok
test python_install::python_install_minor ... ok
test python_install::python_reinstall ... ok
test python_install::python_install_cached ... ok
test python_install::python_install_multiple_patch ... ok
test result: ok. 30 passed; 0 failed; 0 ignored; 0 measured; 2207 filtered out; finished in 23.34s
```
<!--
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? -->
Adding a 3.14 classifier.
## Test Plan
<!-- How was it tested? -->
3.14 is already supported.
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [hashbrown](https://redirect.github.com/rust-lang/hashbrown) |
workspace.dependencies | patch | `0.15.4` -> `0.15.5` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>rust-lang/hashbrown (hashbrown)</summary>
###
[`v0.15.5`](https://redirect.github.com/rust-lang/hashbrown/blob/HEAD/CHANGELOG.md#0155---2025-08-07)
[Compare
Source](https://redirect.github.com/rust-lang/hashbrown/compare/v0.15.4...v0.15.5)
##### Added
- Added `Entry::or_default_entry` and `Entry::or_insert_entry`.
##### Changed
- Re-implemented likely/unlikely with `#[cold]`
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS42MC40IiwidXBkYXRlZEluVmVyIjoiNDEuNjAuNCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
As described in #15179, there are cases where it can be useful to
reinstall the latest patch on upgrade if it is already installed. Using
this flag, you don't need to know ahead of time if you have the latest
patch already.
Closes#15179.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [clap](https://redirect.github.com/clap-rs/clap) |
workspace.dependencies | patch | `4.5.42` -> `4.5.43` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>clap-rs/clap (clap)</summary>
###
[`v4.5.43`](https://redirect.github.com/clap-rs/clap/blob/HEAD/CHANGELOG.md#4543---2025-08-06)
[Compare
Source](https://redirect.github.com/clap-rs/clap/compare/v4.5.42...v4.5.43)
##### Fixes
- *(help)* In long help, list Possible Values before defaults, rather
than after, for a more consistent look
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS42MC40IiwidXBkYXRlZEluVmVyIjoiNDEuNjAuNCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [rui314/setup-mold](https://redirect.github.com/rui314/setup-mold) |
action | digest | `702b190` -> `7344740` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS42MC40IiwidXBkYXRlZEluVmVyIjoiNDEuNjAuNCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| google-github-actions/setup-gcloud | action | digest | `6a7c903` ->
`cb1e50a` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS42MC40IiwidXBkYXRlZEluVmVyIjoiNDEuNjAuNCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [anstream](https://redirect.github.com/rust-cli/anstyle) |
workspace.dependencies | patch | `0.6.19` -> `0.6.20` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>rust-cli/anstyle (anstream)</summary>
###
[`v0.6.20`](https://redirect.github.com/rust-cli/anstyle/compare/anstream-v0.6.19...anstream-v0.6.20)
[Compare
Source](https://redirect.github.com/rust-cli/anstyle/compare/anstream-v0.6.19...anstream-v0.6.20)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS42MC40IiwidXBkYXRlZEluVmVyIjoiNDEuNjAuNCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This fixes our Ruff target Python version for our Python module, which
avoids it enforcing things that break compatibility like
https://github.com/astral-sh/uv/issues/15176
---------
Co-authored-by: arielle <me@arielle.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
Uses a <3.10-compatible version of `zip` since the `strict` argument was
[added in 3.10](https://docs.python.org/3.10/library/functions.html#zip)
## Test Plan
I executed the `_matching_parents` function in a local 3.9 environment
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Automated update for Python releases.
This picks up dynamically-linked tkinter/libtcl/libtk, which fixes#6893
and a host of similar issues.
Co-authored-by: Geoffrey Thomas <geofft@ldpreload.com>
Related to https://github.com/astral-sh/uv/issues/15113
The case in the linked issue is that we perhaps should not be allowing
`uv run --with` with system interpreters at all. I think we can consider
that, but the issue highlighted that `uv run --with` for a system
interpreter is broken if the base interpreter has custom site packages.
This generalizes beyond system interpreters so we should probably fix
our overlays.
A little spicy. We could consider this breaking, but I can't think of
what workflow it'd break and it matches the spirit of `--isolated`. This
was requested by @ssbarnea
Revives https://github.com/astral-sh/uv/pull/9130
Previously, we allowed scoping conflicting extras or groups to specific
packages, e.g. ,`{ package = "foo", extra = "bar" }` for a conflict in
`foo[bar]`. Now, we allow dropping the `extra` or `group` bit and using
`{ package = "foo" }` directly which declares a conflict with `foo`'s
production dependencies.
This means you can declare conflicts between workspace members, e.g.:
```
[tool.uv]
conflicts = [[{ package = "foo" }, { package = "bar" }]]
```
would not allow `foo` and `bar` to be installed at the same time.
Similarly, a conflict can be declared between a package and a group:
```
[tool.uv]
conflicts = [[{ package = "foo" }, { group = "lint" }]]
```
which would mean, e.g., that `--only-group lint` would be required for
the invocation.
As with our existing support for conflicting extras, there are
edge-cases here where the resolver will _not_ fail even if there are
conflicts that render a particular install target unusable. There's test
coverage for some of these. We'll still error at install-time when the
conflicting groups are selected. Due to the likelihood of bugs in this
feature, I've marked it as a preview feature.
I would not recommend reading the commits as there's some slop from not
wanting to rebase Andrew's branch.
---------
Co-authored-by: Andrew Gallant <andrew@astral.sh>
We should definitely not pick up user-level installations unless we
can't find uv anywhere else. Otherwise, e.g., we would find a uv
installed with `pipx install uv` before the one matching the uv module.
We regularly get confusing bug reports where a package sometimes works
and sometimes doesn't and it's not clear to the user why. Ultimately, it
turns out that two packages contain the same module and there is a race
condition when installing the two packages. Usually, it's one of the
opencv-python distributions, but recently it's been z3, too. These error
are completely inscrutable to users.
* https://github.com/astral-sh/uv/issues/10708
* https://github.com/astral-sh/uv/issues/11806
* https://github.com/astral-sh/uv/issues/11659
* https://github.com/astral-sh/uv/issues/13435
* https://github.com/astral-sh/uv/issues/13550
* https://github.com/astral-sh/uv/issues/14030
We now warn for top-level modules (pattern: `<identifier>/__init__.py`)
that collide in a single installation, naming the offending wheels.
Checking for `__init__.py` excludes namespace packages.
Test script:
```
uv venv -q && cargo run -q --profile fast-build pip install --no-progress --link-mode clone opencv-python opencv-contrib-python --no-build --no-deps
uv venv -q && cargo run -q --profile fast-build pip install --no-progress --link-mode copy opencv-python opencv-contrib-python --no-build --no-deps
uv venv -q && cargo run -q --profile fast-build pip install --no-progress --link-mode hardlink opencv-python opencv-contrib-python --no-build --no-deps
uv venv -q && cargo run -q --profile fast-build pip install --no-progress --link-mode symlink opencv-python opencv-contrib-python --no-build --no-deps
```
We currently only catch conflicts in a single installation. Should we
prime the lock database with the site-packages contents, and would that
carry overhead?
<!--
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? -->
At some places the virtualenv directory was manually removed instead of
using `remove_virtualenv`.
I also adjusted the error type.
#14985
## Test Plan
<!-- How was it tested? -->
Follows https://github.com/astral-sh/uv/pull/14181
Two goals here
- Remove duplicated logic and make the search order clear
- Resolve user confusion around the searched directories; we previously
only displayed the last attempt, which we rarely expect to be relevant
## Summary
Addresses zizmor findings in `build-docker.yml`.
Key changes: primarily removing template expansions and restricting some
permissions.
## Test Plan
Let the CI run.
Signed-off-by: William Woodruff <william@astral.sh>
## Summary
uv will now reject ZIP files that meet any of the following conditions:
- Multiple local header entries exist for the same file with different
contents.
- A local header entry exists for a file that isn't included in the
end-of-central directory record.
- An entry exists in the end-of-central directory record that does not
have a corresponding local header.
- The ZIP file contains contents after the first end-of-central
directory record.
- The CRC32 doesn't match between the local file header and the
end-of-central directory record.
- The compressed size doesn't match between the local file header and
the end-of-central directory record.
- The uncompressed size doesn't match between the local file header and
the end-of-central directory record.
- The reported central directory offset (in the end-of-central-directory
header) does not match the actual offset.
- The reported ZIP64 end of central directory locator offset does not
match the actual offset.
We also validate the above for files with data descriptors, which we
previously ignored.
Wheels from the most recent releases of the top 15,000 packages on PyPI
have been confirmed to pass these checks, and PyPI will also reject ZIPs
under many of the same conditions (at upload time) in the future.
In rare cases, this validation can be disabled by setting
`UV_INSECURE_NO_ZIP_VALIDATION=1`. Any validations should be reported to
the uv issue tracker and to the upstream package maintainer.
## Summary
Continuing to burn these down, one at a time.
This eliminates some implicit credentials, moves a permission block to
its minimum scope of effect, and removes an (unexploitable) template
expansion.
@konstin to answer your earlier question: I tried `permissions:` this
time and got a syntax warning, so I suspect it _needs_ to be an empty
mapping object here 🙂
## Test Plan
I will manually dispatch this workflow once the PR is open.
Edit: Dispatched:
https://github.com/astral-sh/uv/actions/runs/16787049700/job/47540074086
Signed-off-by: William Woodruff <william@astral.sh>
Previously, publish would always use the default retries, now it
respects `UV_HTTP_RETRIES`
Some awkward error handling to avoid pulling anyhow into uv-publish.
## Summary
Addresses (mostly minor) findings in `build-binaries.yml`. This is 99%
replacing template expansions with shell-interpolated variables, plus
adding `persist-credentials: false` to every checkout.
## Test Plan
See what happens in CI.
---------
Signed-off-by: William Woodruff <william@astral.sh>
Specifically, support `UV_NO_EDITABLE=1 uv export`. It's now also
supported in `uv add`, though it's default there anyway and the env var
exists only for completeness.
Fixes#15103
## Summary
1. Given the upcoming 1.89 update, this bumps uv-trampoline to "~1.87"
(closest nightly) from "~1.86" (closest nightly).
2. Adds additional CI check for arm builds now that runners are
available.
I wasn't sure the MSRV policy applies to uv-trampoline, so I didn't go
for higher than ~1.87 nightly.
This PR also fixes a build issue starting after 1.87 where fma and fmaf
symbols were missing.
Temporarily dded `#[allow(clippy::ptr_eq)]` to `close_handles` as this
lint should not trigger anymore in 1.88 and above.
## Test Plan
Existing tests and local build process. I did not commit the built
binaries for security purposes.
---------
Co-authored-by: konstin <konstin@mailbox.org>
Previously, `simplify_conflict_markers` assumed that it can remove all
conflict set together, when we need to look at each conflict set
individually. Specifically, `(platform_machine == 'x86_64' and extra ==
'extra-5-foo-b') or extra == 'extra-5-foo-a'` can't be reduced
`platform_machine == 'x86_64'` only because it reduces to true when both
conflict extras are activated.
This case applied in https://github.com/astral-sh/uv/issues/14805, where
a jax 0.5.3 version was used for `platform_machine != 'aarch64' or
sys_platform != 'linux'` and the conflict extra `cu128`, but jax 0.7.0
for the conflict extra `cpu`.
Only removing the faulty inference regresses lockfiles to much more
verbose markers. To balance the much more conservative inference, I
added `unify_inference_sets` to simplify cases where all conflict
branches reduce to the same marker.
This still regresses some markers. For example `sys_platform == 'win32'`
regresses to `sys_platform == 'win32' or (extra == 'extra-3-pkg-x1' and
extra == 'extra-3-pkg-x2')` in `extra_inferences`, even through x1 and
x2 conflict and the second conjunction could be simplified away.
Fixes https://github.com/astral-sh/uv/issues/14805
"Cached request ... is not storable" doesn't make sense from a user
perspective, it's leaking our internal `CachedClient` abstraction. I
think it makes more sense to talk about this as "Response from ... is
not storable"
## Summary
Make the use of `Self` consistent. Mostly done by running `cargo clippy
--fix -- -A clippy::all -W clippy::use_self`.
## Test Plan
<!-- How was it tested? -->
No need.
## Summary
This is an alternative to https://github.com/astral-sh/uv/pull/14944
that functions a little differently. Rather than adding separate
strategies, you can instead say:
```toml
[tool.uv.extra-build-dependencies]
child = [{ requirement = "anyio", match-runtime = true }]
```
Which will then enforce that `anyio` uses the same version as in the
lockfile.
This fixes a regression from 0.8.0 from
https://github.com/astral-sh/uv/pull/7934 and follows
https://github.com/astral-sh/uv/pull/15059
The regression is from [this
change](https://github.com/astral-sh/uv/pull/7934/files#diff-c7a660ac39628d5e12f388b0cacc7360affa3d7bb21191184d7ee78489675e83),
which was made because we'd otherwise (with the other changes in that
pull request) _filter out_ managed Python interpreters found in virtual
environments.
When `--system` is used we'll convert the default Python preference of
`managed` to `system` which avoids things like `uv pip install --system`
targeting a managed Python installation.
The basic test is
```
uv python install
uv pip install --system anyio
```
Prior to this change, we'd read a managed interpreter from our managed
installation directory and target that. After this change, without
#15059, we'd read a managed interpreter from the PATH and target that.
Both of those experiences are bad, because the managed interpreters are
marked as externally managed. After this change, with #15059, we
properly target the system interpreter.
Since we use `system` instead of `only-system`, if there is not a system
interpreter we'll still retain our existing behavior and use a managed
interpreter. This should limit breakage from the change. Given the
source of the regression, we could probably use `only-system` here. I
don't feel strongly. I think the main benefit of doing so would be that
we'd omit the check for managed installations in error messages when an
interpreter cannot be found?
We can't really add test coverage here because the test suite always has
externally managed interpreters :)
## Summary
I should've noticed this during review -- my bad -- but it looks like
after lowering, we're converting back to `uv_pep508::Requirement`. This
is mostly okay, but it's lossy for some lowerings. For example, we lose
index pinning. With this PR, we now preserve the lowered types
(`Requirement`).
Closes https://github.com/astral-sh/uv/issues/15037.
This is the first part of fixing a 0.8.0 regression from
https://github.com/astral-sh/uv/pull/7934
There, we added handling for skipping managed interpreters on the PATH
when `only-system` is used, but did not update the logic to prefer
system interpreters over managed ones when `system` is used. Here, we
fix that by skipping managed interpreters when `system` is used unless
_only_ managed interpreters are available. While this logic is applied
during in a general discovery method, it's only relevant for the PATH
(and the Windows registry) because we already change the _order_ that we
inspect installations in when `system` is used, so the managed
installation directory is inspected last.
This behavior did not regress in 0.8, it's always been this way,
however, I need this change in order to fix a different bug.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| google-github-actions/auth | action | digest | `140bb51` -> `b7593ed`
|
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS41MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNTEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [rkyv](https://redirect.github.com/rkyv/rkyv) | workspace.dependencies
| patch | `0.8.10` -> `0.8.11` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [x] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS41MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNTEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [serde_json](https://redirect.github.com/serde-rs/json) |
workspace.dependencies | patch | `1.0.141` -> `1.0.142` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>serde-rs/json (serde_json)</summary>
###
[`v1.0.142`](https://redirect.github.com/serde-rs/json/releases/tag/v1.0.142)
[Compare
Source](https://redirect.github.com/serde-rs/json/compare/v1.0.141...v1.0.142)
- impl Default for \&Value
([#​1265](https://redirect.github.com/serde-rs/json/issues/1265),
thanks [@​aatifsyed](https://redirect.github.com/aatifsyed))
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [x] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS41MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNTEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [clap](https://redirect.github.com/clap-rs/clap) |
workspace.dependencies | patch | `4.5.41` -> `4.5.42` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>clap-rs/clap (clap)</summary>
###
[`v4.5.42`](https://redirect.github.com/clap-rs/clap/blob/HEAD/CHANGELOG.md#4542---2025-07-30)
[Compare
Source](https://redirect.github.com/clap-rs/clap/compare/v4.5.41...v4.5.42)
##### Fixes
- Include subcommand visible long aliases in `--help`
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [x] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS41MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNTEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Following a CI failure in https://github.com/astral-sh/uv/pull/15028,
ensure that all workspace crates are inheriting the MSRV and other
workspace configuration from the workspace root.
## Summary
We weren't including these in the cache key when constructing the
install plan. We likely still read them from the cache later, but we may
have reported the wrong number of prepares, etc.
Apply fixes for some `cargo check` and `cargo clippy` lints that are on
in nightly Rust.
The following command now passes, the blanket allows had to many
false-positives:
```
cargo +nightly clippy -- -A clippy::doc_markdown -A mismatched_lifetime_syntaxes -A clippy::explicit_deref_methods
```
`cargo +nightly check -- -A mismatched_lifetime_syntaxes` now passes
without warnings.
Gracefully handle entrypoint permission errors
`uv run --with` could fail with a "permission denied" error when it
tried to copy an entrypoint with restrictive permissions.
For instance:
```sh
$ stat -c '%A' /usr/bin/groupmems
-rwxr-s---
$ uv python find
/usr/bin/python
$ uv run --with dummy_test
error: failed to open file `/usr/bin/groupmems`: Permission denied (os error 13)
```
The entrypoint copying logic now catches these permission errors and
skips the file, making `uv` more resilient on systems with binaries that
have restrictive permissions.
## Summary
We often match on `ErrorKind` to figure out how to handle an error
(e.g., to treat a 404 as "Not found" rather than aborting the program).
Unfortunately, if we retry, we wrap the error in a new kind that
includes the retry count. This PR adds an unwrapping mechanism to ensure
that callers always look at the underlying error.
Closes https://github.com/astral-sh/uv/issues/14941.
Closes https://github.com/astral-sh/uv/issues/14989.
## Summary
This just looks like an oversight. We weren't including hashes from
local Simple API indexes if a package had both a wheel and a source
distribution.
Closes https://github.com/astral-sh/uv/issues/14883
## Summary
The basic problem here is that when we had multiple items in an inline
array, and that array expanded to multiple lines, we accidentally
changed the indentation part-way through due to how prefixes work in the
TOML.
Here's Claude's explanation of the root cause, which I find pretty
decent:
```
Here's what happened step by step:
1. First item ("iniconfig"): Has empty prefix "" → indentation_prefix stays None → uses default 4 spaces
2. Second item ("ruff"): Has empty prefix "" → indentation_prefix stays None → uses default 4 spaces
3. Third item ("typing-extensions"): Has prefix " " (single space from inline format) → indentation_prefix becomes
Some(" ") → uses only 1 space!
This produced:
[dependency-groups]
dev = [
"iniconfig>=2.0.0",
"ruff",
"typing-extensions", # ← Only 1 space instead of 4!
]
Why the Third Item Had a Different Prefix
In inline arrays like ["ruff", "typing-extensions"], the items are separated by commas and spaces. When parsed by
the TOML library:
- "ruff" has no prefix (it comes right after [)
- "typing-extensions" has a single space prefix (the space after the comma)
The Fix
Moving the indentation calculation outside the loop ensures it's calculated only once:
// Calculate indentation ONCE before the loop
if let Some(first_item) = deps.iter().next() {
let decor_prefix = /* get prefix from first item */
indentation_prefix = (!decor_prefix.is_empty()).then_some(decor_prefix.to_string());
}
// Now use the same indentation for ALL items
for item in deps.iter_mut() {
// Apply consistent indentation to every item
}
This ensures all items get the same indentation (4 spaces by default when converting from inline arrays), producing
the correct output:
[dependency-groups]
dev = [
"iniconfig>=2.0.0",
"ruff",
"typing-extensions", # ← Correct 4-space indentation
]
The bug only affected arrays being converted from inline to multiline format, where different items might have
different residual formatting from their inline representation.
```
Closes#14961.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
This is a bit of a weird request, but in [pixi](https://pixi.sh) we are
making use of this function to lazily instantiate a conda environment.
Well, in actuality we are using a shim to the `BuildDispatch` to
actually to only create a conda prefix, if some package needs to be
built during the resolution phase. Otherwise we can resolve everything
without an enviroment containing a python intepreter.
We are using a method now - that uses the runtime to run async code
inside this function, as `interpreter` is the first method called on a
`BuildContext` when running a source build - using
`tokio::Handle::block_on`.
However was causing a deadlock in very specific situations, me and
@baszalmstra + @wolfv have investigated this thoroughly, but have not
been able to find the root cause. It would hang in a part of the uv code
that hits the index, but that is **after** all of our initialization
*and the blocking call* was completed.
Changing this to be fully async fixes the problem, this requires this
method to be async though.
We get that this is not necessarily required, and we might find a
workaround, but I wanted to try it this way first.
Thanks!
Close#6314
## Summary
Continuing from #7592. Created a new PR to rebase the old branch with
`main`, cleaned up test errors, and improved readability.
## Test Plan
Same test cases as in #7592.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
In https://github.com/astral-sh/uv/issues/14919 it was reported that
uv's behavior differed after the first invocation. I noticed we weren't
copying entrypoints after the first invocation. It turns out the
shebangs were written with `.../python` but on a subsequent invocation
the `sys.executable` was `.../python3` so we didn't detect these as
matching.
This is a pretty naive fix, but it seems much easier than ensuring the
entry point path exactly matches the subsequent `sys.executable` we
find.
I guess we should fix this in reverse too? but I think we might always
prefer `python3` when loading interpreters from environments.
See #14790 for more background.
Replaces https://github.com/astral-sh/uv/pull/14092
Adds `tool.uv.extra-build-dependencies = {package = [dependency, ...]}`
which extends `build-system.requires` during package builds.
These are lowered via workspace sources, are applied to transitive
dependencies, and are included in the wheel cache shard hash.
There are some features we need to follow-up on, but are out of scope
here:
- Preferring locked versions for build dependencies
- Settings for requiring locked versions for build depencies
There are some quality of life follow-ups we should also do:
- Warn on `extra-build-dependencies` that do not apply to any packages
- Add test cases and improve error messaging when the
`extra-build-dependencies` resolve fails
-------
There ~are~ were a few open decisions to be made here
1. Should we resolve these dependencies alongside the
`build-system.requires` dependencies? Or should we resolve separately?
(I think the latter is more powerful? because you can override things?
but it opens the door to breaking your build)
2. Should we install these dependencies into the same environment? Or
should we layer it on top as we do elsewhere? (I think it's fine to
install into the same environment)
3. Should we respect sources defined in the parent project? (I think
yes, but then we need to lower the dependencies earlier — I don't think
that's a big deal, but it's not implemented)
4. Should we respect sources defined in the child project? (I think no,
this gets really complicated and seems weird to allow)
5. Should we apply this to transitive dependencies? (I think so)
---------
Co-authored-by: Aria Desires <aria.desires@gmail.com>
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
I noticed what appears to be a small typo in the documentation. In the
section describing dev versions, it says `sbpth table releases`. I
believe this was meant to be `both stable releases`, to match the
structure of the previous sentence about post versions.
We do not just "ignore" the existing lockfile here. We retain the
existing messaging for cases where we do actually throw out the
lockfile, like `--upgrade`.
Adds `exclude-newer-package = { package = timestamp, ... } ` and
`--exclude-newer-package package=timestamp`. These take precedence over
`exclude-newer` for a given package.
This does need to be serialized to the lockfile, so the revision is
bumped to 3. I tested a previous version and we can read a lockfile with
this information just fine.
Closes https://github.com/astral-sh/uv/issues/14394
Adds a cache bucket for Python installs and uses it by default during
tests, extending the opt-in cache added in
https://github.com/astral-sh/uv/pull/12175
Updates the `python_install` tests to use a shared cache for Python
installs. This reduces the `python_install` test runtime on my machine
from 23s -> 17s. The difference should be much larger on machines with
slower internet and less cores for test workers :) This should also
improve stability in CI by reducing reliance on the network during test
runs, see #14327
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[astral-sh/ruff-pre-commit](https://redirect.github.com/astral-sh/ruff-pre-commit)
| repository | patch | `v0.12.4` -> `v0.12.5` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
Note: The `pre-commit` manager in Renovate is not supported by the
`pre-commit` maintainers or community. Please do not report any problems
there, instead [create a Discussion in the Renovate
repository](https://redirect.github.com/renovatebot/renovate/discussions/new)
if you have any questions.
---
### Release Notes
<details>
<summary>astral-sh/ruff-pre-commit (astral-sh/ruff-pre-commit)</summary>
###
[`v0.12.5`](https://redirect.github.com/astral-sh/ruff-pre-commit/releases/tag/v0.12.5)
[Compare
Source](https://redirect.github.com/astral-sh/ruff-pre-commit/compare/v0.12.4...v0.12.5)
See: https://github.com/astral-sh/ruff/releases/tag/0.12.5
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS40MC4wIiwidXBkYXRlZEluVmVyIjoiNDEuNDAuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Fixes#14920
## Summary
Problem: When building wheel packages, metadata files (such as RECORD,
METADATA, WHEEL, and
license files) were being created with incorrect Unix permissions
(--w--wx---), lacking
read permissions and having unexpected executable permissions.
Solution: The fix ensures that all metadata files in wheel packages are
created with proper
644 (rw-r--r--) permissions by:
- Adding explicit unix_permissions(0o644) setting in the write_bytes
method for metadata
files
- Updating permission constants to use octal notation for clarity
- Improving code comments to document the permission settings
Impact: This change ensures wheel packages created by uv have standard
file permissions
consistent with other Python build tools like setuptools, improving
compatibility and
following Python packaging best practices.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [criterion](https://bheisler.github.io/criterion.rs/book/index.html)
([source](https://redirect.github.com/bheisler/criterion.rs)) |
dependencies | minor | `0.6.0` -> `0.7.0` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>bheisler/criterion.rs (criterion)</summary>
###
[`v0.7.0`](https://redirect.github.com/bheisler/criterion.rs/blob/HEAD/CHANGELOG.md#070---2025-07-25)
[Compare
Source](https://redirect.github.com/bheisler/criterion.rs/compare/0.6.0...0.7.0)
- Bump version of criterion-plot to align dependencies.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS40MC4wIiwidXBkYXRlZEluVmVyIjoiNDEuNDAuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [tokio](https://tokio.rs)
([source](https://redirect.github.com/tokio-rs/tokio)) |
workspace.dependencies | minor | `1.46.1` -> `1.47.0` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>tokio-rs/tokio (tokio)</summary>
###
[`v1.47.0`](https://redirect.github.com/tokio-rs/tokio/releases/tag/tokio-1.47.0):
Tokio v1.47.0
[Compare
Source](https://redirect.github.com/tokio-rs/tokio/compare/tokio-1.46.1...tokio-1.47.0)
##### 1.47.0 (July 25th, 2025)
This release adds `poll_proceed` and `cooperative` to the `coop` module
for
cooperative scheduling, adds `SetOnce` to the `sync` module which
provides
similar functionality to \[`std::sync::OnceLock`], and adds a new method
`sync::Notify::notified_owned()` which returns an `OwnedNotified`
without
a lifetime parameter.
##### Added
- coop: add `cooperative` and `poll_proceed` ([#​7405])
- sync: add `SetOnce` ([#​7418])
- sync: add `sync::Notify::notified_owned()` ([#​7465])
##### Changed
- deps: upgrade windows-sys 0.52 → 0.59
(\[[#​7117](https://redirect.github.com/tokio-rs/tokio/issues/7117)])
- deps: update to socket2 v0.6
(\[[#​7443](https://redirect.github.com/tokio-rs/tokio/issues/7443)])
- sync: improve `AtomicWaker::wake` performance ([#​7450])
##### Documented
- metrics: fix listed feature requirements for some metrics
([#​7449])
- runtime: improve safety comments of `Readiness<'_>` ([#​7415])
[#​7405]: https://redirect.github.com/tokio-rs/tokio/pull/7405
[#​7415]: https://redirect.github.com/tokio-rs/tokio/pull/7415
[#​7418]: https://redirect.github.com/tokio-rs/tokio/pull/7418
[#​7449]: https://redirect.github.com/tokio-rs/tokio/pull/7449
[#​7450]: https://redirect.github.com/tokio-rs/tokio/pull/7450
[#​7465]: https://redirect.github.com/tokio-rs/tokio/pull/7465
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS40MC4wIiwidXBkYXRlZEluVmVyIjoiNDEuNDAuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.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
<!-- What's the purpose of the change? What does it do, and why? -->
This revisits https://github.com/astral-sh/uv/pull/14364, which was
opened by the renovate bot and originally failed with an error I don’t
quite understand in
https://github.com/astral-sh/uv/pull/14364#issuecomment-3017545431.
Since 852aba4f90 updated to `indicatif`
0.18, we now already have `console` 0.16 in the dependency tree. This PR
adjusts the direct dependency on `console` to match.
The only breaking change in [`console`
0.16.0](https://github.com/console-rs/console/releases/tag/0.16.0) is
that crates that depend on `console` with `default-features = False` may
need to explicitly enable the new `std` feature. This is the case for
`uv`: while I did find that `cargo test` passes with just the `console`
dependency version adjusted, this is due to [feature
unification](https://doc.rust-lang.org/cargo/reference/features.html#feature-unification),
i.e., the indirect dependency on `console` via `indicatif` 0.18 already
requires its `std` feature. We can see by inspection that `uv` should
also have a direct dependency on `console` with the `std` feature. For
example, see:
05031becc3/crates/uv-console/src/lib.rs (L1)
and note that `Term` is gated by the `std` feature in
a51fcead7c/src/lib.rs (L90-L93)
The addition of `features = ["std"]` is the key difference between this
PR and https://github.com/astral-sh/uv/pull/14364.
## Test Plan
<!-- How was it tested? -->
`cargo test`
I think this would give us better hygiene than a global flag. It makes
it easier for users to opt-in to overlapping features, such as Python
upgrades and Python bin installations and to disable warnings for
preview mode without opting in to a bunch of other features. In general,
I want to reduce the burden for putting something under preview.
The `--preview` and `--no-preview` flags are retained as global
overrides. A new `--preview-features` option is added which accepts
comma separated features or can be passed multiple times, e.g.,
`--preview-features add-bounds,pylock`. There's a `UV_PREVIEW_FEATURES`
environment variable for that option (I'm not sure if we should overload
`UV_PREVIEW`, but could be convinced).
`Candidate` has an optional field `prioritized`, which was mostly
redundant with `CandidateDist`. Specifically, it was only `None`, if
`CandidateDist` was `Installed`. This commit removes this duplication.
## Summary
This is an alternative to #14003 that takes advantage of the fact that
we already validate that the requirements are up-to-date when validating
the lockfile, and the requirements for pinned requirements include the
index itself -- so rather than collecting all the explicit indexes
upfront, we can just add them to the available list as we iterate over
the lockfile's dependency graph.
This gets all the tests passing from that PR, but with ~no performance
impact and a much less invasive change. It also gets the "circular
dependency" test passing, which is marked with a TODO in that PR.
Closes https://github.com/astral-sh/uv/issues/11419.
It seems that non-standard entrypoints are still widely used,
downgrading the error to a tracing warning.
Fixes#14442
---------
Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com>
## Summary
This fixes a regression from https://github.com/astral-sh/uv/pull/14447
that we seemingly didn't have test coverage for. Specifically, if you
have a version of a package in your project, and then install a
different version with `--with`, the environment should import the
`--with` version.
Closes#14860.
## Summary
The core problem here is that `allowed_indexes` only includes at most
one "default" index. This is problematic for tool upgrades, since the
index in the receipt will be marked as default, but credentials will be
omitted; if credentials are then defined in a `uv.toml`, we'll never
look at those, since that will _also_ be marked as default, and we only
look at the first default.
Instead, we should consider all defined indexes in priority order.
Closes https://github.com/astral-sh/uv/issues/14806.
## Summary
Right now, we write index URLs to the tool receipt with redacted
credentials (i.e., a username, and `****` in lieu of a password). This
is always wrong and unusable. Instead, this PR drops them entirely.
Part of https://github.com/astral-sh/uv/issues/14806.
<!--
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
We are using UV as a library and need to set `tls_built_in_root_certs`
on the reqwest client.
This PR exposes this property in the `BaseClientBuilder` and in the
`RegistryClientBuilder`. The default is set to `false`, so this does not
change any behaviour unless you explicitly opt into it.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
## Summary
A little nuanced, but... When you add multiple `--index` URLs on the CLI
(e.g., in `uv pip install`), we check the first-provided index, then the
second index, etc. However, when we _write_ those URLs to the
`pyproject.toml` in `uv add`, we were adding them in reverse-order. We
now add them in a way that preserves the priority order.
Closes https://github.com/astral-sh/uv/issues/14817.
## Summary
This PR adds derivation chain for another class of resolver failures.
For example, if we encounter a transitive URL dependency, we now tell
the user which package included it, and the full derivation chain:
```
× Failed to resolve dependencies for `foo` (v0.1.0)
╰─▶ Package `flask` was included as a URL dependency. URL dependencies must be
expressed as direct requirements or constraints. Consider adding `flask @
9d4508e893f34853a30fd769c02e9d/flask-3.1.1-py3-none-any.whl`
to your dependencies or constraints file.
help: `foo` (v0.1.0) was included because `baz` (v0.1.0) depends on `foo`
```
Closes#14795.
When users run `uv version` in a directory without a `pyproject.toml`
file, they often intend to check uv's own version rather than a
project's version. This change adds a helpful hint to guide users to the
correct command.
**Before:**
```
❯ uv version
error: No `pyproject.toml` found in current directory or any parent directory
```
**After:**
```
❯ uv version
error: No `pyproject.toml` found in current directory or any parent directory
hint: If you meant to view uv's version, use `uv self version` instead
```
## Changes
- Modified `find_target()` function in
`crates/uv/src/commands/project/version.rs` to catch
`WorkspaceError::MissingPyprojectToml` specifically and enhance the
error message with a helpful hint
- Added import for `WorkspaceError` to access the specific error type
- Updated existing tests to expect the new hint message in error output
- Added new test case `version_get_missing_with_hint()` to verify
behavior
The hint appears consistently across all scenarios where `uv version`
fails to find a project:
- `uv version` (normal mode)
- `uv version --project .` (explicit project mode)
- `uv version --preview` (preview mode)
The change maintains all existing functionality - when a
`pyproject.toml` is found, `uv version` continues to work normally
without showing the hint.
Fixes#14730.
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>
## Summary
Closes#12163.
## Test Plan
Created an offending source distribution with this script:
```python
import io
import tarfile
import textwrap
import time
PKG_NAME = "badpkg"
VERSION = "0.1"
DIST_NAME = f"{PKG_NAME}-{VERSION}"
ARCHIVE = f"{DIST_NAME}.tar.gz"
def _bytes(data: str) -> io.BytesIO:
"""Helper: wrap a text blob as a BytesIO for tarfile.addfile()."""
return io.BytesIO(data.encode())
def main(out_path: str = ARCHIVE) -> None:
now = int(time.time())
with tarfile.open(out_path, mode="w:gz") as tar:
def add_file(path: str, data: str, mode: int = 0o644) -> None:
"""Add a regular file whose *content* is supplied as a string."""
buf = _bytes(data)
info = tarfile.TarInfo(path)
info.size = len(buf.getbuffer())
info.mtime = now
info.mode = mode
tar.addfile(info, buf)
# ── top‑level setup.py ───────────────────────────────────────────────
setup_py = textwrap.dedent(f"""\
from setuptools import setup, find_packages
setup(
name="{PKG_NAME}",
version="{VERSION}",
packages=find_packages(),
)
""")
add_file(f"{DIST_NAME}/setup.py", setup_py)
# ── minimal package code ─────────────────────────────────────────────
add_file(f"{DIST_NAME}/{PKG_NAME}/__init__.py", "# placeholder\\n")
# ── the malicious symlink ────────────────────────────────────────────
link = tarfile.TarInfo(f"{DIST_NAME}/{PKG_NAME}/evil_link")
link.type = tarfile.SYMTYPE
link.mtime = now
link.mode = 0o777
link.linkname = "../../../outside.txt"
tar.addfile(link)
print(f"Created {out_path}")
if __name__ == "__main__":
main()
```
Verified that both `pip install` and `uv pip install` rejected it.
I also changed `link.linkname = "../../../outside.txt"` to
`link.linkname = "/etc/outside"`, and verified that the absolute path
was rejected too.
This is an alternative to https://github.com/astral-sh/uv/pull/14788
which has the benefit that it addresses
https://github.com/astral-sh/uv/issues/13327 which would be an issue
even if we reverted #14447.
There are two changes here
1. We copy entry points into the ephemeral environment, and rewrite
their shebangs (or trampoline target) to ensure the ephemeral
environment is not bypassed.
2. We link `etc/jupyter` and `share/jupyter` data directories into the
ephemeral environment, this is in order to ensure the above doesn't
break Jupyter which unfortunately cannot find the `share` directory
otherwise. I'd love not to do this, as it seems brittle and we don't
have a motivating use-case beyond Jupyter. I've opened
https://github.com/jupyterlab/jupyterlab/issues/17716 upstream for
discussion, as there is a viable patch that could be made upstream to
resolve the problem. I've limited the fix to Jupyter directories so we
can remove it without breakage.
Closes https://github.com/astral-sh/uv/issues/14729
Closes https://github.com/astral-sh/uv/issues/13327
Closes https://github.com/astral-sh/uv/issues/14749
---------
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
fix some minor issues in comments
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
Signed-off-by: pingshuijie <pingshuijie@outlook.com>
## Summary
If `HF_TOKEN` is set, we'll automatically wire it up to authenticate
requests when hitting private `huggingface.co` URLs in `uv run`.
## Test Plan
An unauthenticated request:
```
> cargo run -- run https://huggingface.co/datasets/cmarsh/test/resolve/main/main.py
File "/var/folders/nt/6gf2v7_s3k13zq_t3944rwz40000gn/T/mainYadr5M.py", line 1
Invalid username or password.
^^^^^^^^
SyntaxError: invalid syntax
```
An authenticated request:
```
> HF_TOKEN=hf_... cargo run run https://huggingface.co/datasets/cmarsh/test/resolve/main/main.py
Hello from main.py!
```
I updated the Github Actions integration guide to run Github's
`setup-python` before Astral's `setup-uv`, as `setup-uv`'s
`activate-environment: true` doesn't work with the original ordering.
There is a discussion about this behavior in the `setup-uv` repo
[here](https://github.com/astral-sh/setup-uv/issues/479).
<!--
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
Update the documentation for the Github Actions integration. Caveat: I'm
unsure if there are any other reasons where the original ordering (that
is,`setup-uv` before `setup-python`) might be preferred.
## Test Plan
Tested in a private Github Actions push, as documented in the
aforementioned discussion on `setup-uv`'s repo. Confirmed that removing
`source .venv/bin/activate` and replacing it with `activate-environment:
true` now works in this ordering (but didn't work with the original
ordering where `uv` installs before Github's `python`).
We currently have two marker keys that a list, `extras` and
`dependency_groups`, both from PEP 751. With the variants PEP, we will
add three more. This change is broken out of the wheel variants PR to
introduce generic marker list support, plus a change to use
`ContainerOperator` in more places.
## Summary
I found it confusing that the `else` case for `== "graalpy"` is still
necessary for the `== "pypy"` branch (i.e., that `pythonw.exe` is copied
for PyPy despite not being in the `== "pypy"` branch).
Instead, we now use a match for PyP, GraalPy, and then everything else.
The `version_get_fallback_unmanaged_json` test was failing when running
tests outside of a git checkout (e.g., from a release tarball) due to
inconsistent behavior based on git availability.
The test had conditional logic that expected different outcomes
depending on whether `git_version_info_expected()` returned true or
false:
- In git checkouts: Expected failure with "The project is marked as
unmanaged" error
- Outside git checkouts: Expected success with fallback behavior showing
version info
However, the fallback behavior was removed in version 0.8.0, making this
test obsolete. All other similar tests
(`version_get_fallback_unmanaged`,
`version_get_fallback_unmanaged_short`,
`version_get_fallback_unmanaged_strict`) consistently expect failure
when a project is marked as unmanaged, regardless of git availability.
This change removes the problematic test entirely, as suggested by
@zanieb. All remaining version tests (51 total) continue to pass.
Fixes#14785.
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>
## Summary
This should give us some performance and error message improvements.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
We don't yet support writing these, but we can at least read them
(which, e.g., allows you to install PDM-exported `pylock.toml` files
with uv, since PDM _always_ writes a default group).
Closes#14740.
## Summary
Follow #14078, use GitHub generated sha256 for GraalPy releases too.
## Test Plan
```console
uv run ./crates/uv-python/fetch-download-metadata.py
```
## Summary
Rename `_parse_download_url` to `_parse_download_asset` and move the
`asset['digest']` logic into it.
## Test Plan
```console
uv run ./crates/uv-python/fetch-download-metadata.py
```
## Summary
A refactor that I'm extracting from #14755. There should be no
functional changes, but the core idea is to postpone filling in the
default `path` for a dependency group until we make the specification.
This allows us to use the groups for the `pylock.toml` in the future, if
such a `pylock.toml` is provided.
## Summary
This was just an oversight on my part in the initial implementation.
Closes https://github.com/astral-sh/uv/issues/14719.
## Test Plan
With:
```toml
[project]
name = "foo"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.13.2"
dependencies = [
]
[[tool.uv.index]]
url = "https://download.pytorch.org/whl/cpu"
cache-control = { api = "max-age=600" }
```
Ran `cargo run lock -vvv` and verified that the PyTorch index response
was cached (whereas it typically returns `cache-control:
no-cache,no-store,must-revalidate`).
With the previous order of operations, there could be warnings from race
conditions between two process A and B removing and installing Python
versions.
* A removes the files for CPython3.9.18
* B sees the key CPython3.9.18
* B sees that CPython3.9.18 has no files
* A removes the key for CPython3.9.18
* B try to removes the key for CPython3.9.18, gets and error that it's
already gone, issues a warning
We make the more resilient in two ways:
* We remove the registry key first, avoiding dangling registry keys in
the removal process
* We ignore not found errors in registry removal operations: If we try
to remove something that's already gone, that's fine.
Fixes#14714 (hopefully)
Reviewing #14687, I noticed that we had implemented a
`Url::from_url_or_path`-like function, but it wasn't reusable. This
change `Verbatim::from_url_or_path` so we can use it in other places
too.
The PEP 508 parser is an odd place for this, but that's where
`VerbatimUrl` and `Scheme` are already living.
We recently ran over the file limit and had to drop hash file from the
releases page in favor of bulk SHA256SUMS files
(https://github.com/astral-sh/python-build-standalone/pull/691).
Conveniently, GitHub has recently started to add a SHA256 digest to the
API. GitHub did not backfill the hashes for the old releases, so use the
API hashes for newer assets, and eventually only download SHA256SUMS for
older releases.
I must have Googled something too fast, sorry. glibc 2.28 came out
August 2018, Fedora 29 was the earliest to ship with it in October 2018,
Debian 10 shipped with it in July 2019, and CentOS 8 shipped with it in
September 2019.
We currently treat path sources as virtual if they do not specify a
build system, which is surprising behavior. This PR updates the behavior
to treat path sources as packages unless the path source is explicitly
marked as `package = false` or its own `tool.uv.package` is set to
`false`.
Closes#12015
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
By default, `uv venv <venv-name>` currently removes the `<venv-name`>
directory if it exists. This can be surprising behavior: not everyone
expects an existing environment to be overwritten. This PR updates the
default to fail if a non-empty `<venv-name>` directory already exists
and neither `--allow-existing` nor the new `-c/--clear` option is
provided (if a TTY is detected, it prompts first). If it's not a TTY,
then uv will only warn and not fail for now — we'll make this an error
in the future. I've also added a corresponding `UV_VENV_CLEAR` env var.
I've chosen to use `--clear` instead of `--force` for this option
because it is used by the `venv` module and `virtualenv` and will be
familiar to users. I also think its meaning is clearer in this context
than `--force` (which could plausibly mean force overwrite just the
virtual environment files, which is what our current `--allow-existing`
option does).
Closes#1472.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
In the case of `uv sync` all we really need to do is handle the
`OutdatedEnvironment` error (precisely the error we yield only on
dry-runs when everything Works but we determine things are outdated) in
`OperationDiagnostic::report` (the post-processor on all
`operations::install` calls) because any diagnostic handled by that gets
downgraded to from status 2 to status 1 (although I don't know if that's
really intentional or a random other bug in our status handling... but I
figured it's best to highlight that other potential status code
incongruence than not rely on it 😄).
Fixes#12603
---------
Co-authored-by: John Mumm <jtfmumm@gmail.com>
We weren't following our usual "destructure all the options" pattern in
this function, and several "this isn't actually read from uv.toml"
fields slipped through the cracks over time since folks forgot it
existed.
Fixes part of #14308, although we could still try to make the warning in
FilesystemOptions more accurate?
You could argue this is a breaking change, but I think it ultimately
isn't really, because we were already silently ignoring these fields.
Now we properly error.
If a user specifies `-e /path/to/dir` and `/path/to/dir` in a `uv pip
install` command, we want the editable to "win" (rather than erroring
due to conflicting URLs). Unfortunately, this behavior meant that when
you requested a package as editable and non-editable in conflicting
groups, the editable version was _always_ used. This PR modifies the
requisite types to use `Option<bool>` rather than `bool` for the
`editable` field, so we can determine whether a requirement was
explicitly requested as editable, explicitly requested as non-editable,
or not specified (as in the case of `/path/to/dir` in a
`requirements.txt` file). In the latter case, we allow editables to
override the "unspecified" requirement.
If a project includes a path dependency twice, once with `editable =
true` and once without any `editable` annotation, those are now
considered conflicting URLs, and lead to an error, so I've marked this
change as breaking.
Closes https://github.com/astral-sh/uv/issues/14139.
If `--workspace` is provided, we add all paths as workspace members.
If `--no-workspace` is provided, we add all paths as direct path
dependencies.
If neither is provided, then we add any paths that are under the
workspace root as workspace members, and the rest as direct path
dependencies.
Closes#14524.
While reviewing https://github.com/astral-sh/uv/pull/14107, @oconnor663
pointed out a bug where we allow `uv python pin --rm` to delete the
global pin without the `--global` flag. I think that shouldn't be
allowed? I'm not 100% certain though.
Closes#13057
Sets `UV_TOOL_BIN_DIR` to `/usr/local/bin` for all derived images to
allow `uv tool install` to work out of the box.
Note, when the default image user is overwritten (e.g. `USER <UID>`) by
a less privileged one, an alternative writable location would now need
to be set by downstream consumers to prevent issues, hence I'm labeling
this as a breaking change for 0.8.x release.
Relates to https://github.com/astral-sh/uv-docker-example/pull/55
Each image was tested to work with uv tool with `UV_TOOL_BIN_DIR` set to
`/usr/local/bin` with the default root user and alternative non-root
users to confirm breaking nature of the change.
Adds environment variables for
https://github.com/astral-sh/uv/pull/14612 and
https://github.com/astral-sh/uv/pull/14614
We can't use the Clap `BoolishValueParser` here, and the reasoning is a
little hard to explain. If we used `UV_PYTHON_INSTALL_NO_BIN`, as is our
typical pattern, it'd work, but here we allow opt-in to hard errors with
`UV_PYTHON_INSTALL_BIN=1` and I don't think we should have both
`UV_PYTHON_INSTALL_BIN` and `UV_PYTHON_INSTALL_NO_BIN`.
Consequently, this pull request introduces a new `EnvironmentOptions`
abstraction which allows us to express semantics that Clap cannot —
which we probably want anyway because we have an increasing number of
environment variables we're parsing downstream, e.g., #14544 and #14369.
2025-07-17 12:33:43 -05:00
933 changed files with 130823 additions and 33625 deletions
// N.B. We do not show the `service_name` here because we'll show the warning twice
// otherwise, once for the URL and once for the realm.
warn_user_once!(
"Attempted to fetch credentials using the `keyring` command, but it does not support `--mode creds`; upgrade to `keyring>=v25.2.1` for support or provide a username"
"Attempted to fetch credentials using the `keyring` command, but it does not support `--mode creds`; upgrade to `keyring>=v25.2.1` or provide a username"
);
}elseifusername.is_none(){
// If we captured stderr, display it in case it's helpful to the user
#[error("Glob expressions caused to large regex in: `{field}`")]
#[error("Glob expressions caused to large regex in: {field}")]
GlobSetTooLarge{
field: String,
#[source]
@ -49,7 +53,7 @@ pub enum Error {
},
#[error("`pyproject.toml` must not be excluded from source distribution build")]
PyprojectTomlExcluded,
#[error("Failed to walk source tree: `{}`", root.user_display())]
#[error("Failed to walk source tree: {}", root.user_display())]
WalkDir{
root: PathBuf,
#[source]
@ -59,14 +63,19 @@ pub enum Error {
Zip(#[from]zip::result::ZipError),
#[error("Failed to write RECORD file")]
Csv(#[from]csv::Error),
#[error("Expected a Python module at: `{}`", _0.user_display())]
#[error("Expected a Python module at: {}", _0.user_display())]
MissingInitPy(PathBuf),
#[error("For namespace packages, `__init__.py[i]` is not allowed in parent directory: `{}`", _0.user_display())]
#[error("For namespace packages, `__init__.py[i]` is not allowed in parent directory: {}", _0.user_display())]
NotANamespace(PathBuf),
/// Either an absolute path or a parent path through `..`.
#[error("Module root must be inside the project: `{}`", _0.user_display())]
#[error("Module root must be inside the project: {}", _0.user_display())]
InvalidModuleRoot(PathBuf),
#[error("Inconsistent metadata between prepare and build step: `{0}`")]
/// Either an absolute path or a parent path through `..`.
#[error("The path for the data directory {} must be inside the project: {}", name, path.user_display())]
InvalidDataRoot{name: String,path: PathBuf},
#[error("Virtual environments must not be added to source distributions or wheels, remove the directory or exclude it from the build: {}", _0.user_display())]
VenvInSourceTree(PathBuf),
#[error("Inconsistent metadata between prepare and build step: {0}")]
InconsistentSteps(&'staticstr),
#[error("Failed to write to {}", _0.user_display())]
TarWrite(PathBuf,#[source]io::Error),
@ -185,6 +194,60 @@ fn check_metadata_directory(
Ok(())
}
/// Returns the list of module names without names which would be included twice
///
/// In normal cases it should do nothing:
///
/// * `["aaa"] -> ["aaa"]`
/// * `["aaa", "bbb"] -> ["aaa", "bbb"]`
///
/// Duplicate elements are removed:
///
/// * `["aaa", "aaa"] -> ["aaa"]`
/// * `["bbb", "aaa", "bbb"] -> ["aaa", "bbb"]`
///
/// Names with more specific paths are removed in favour of more general paths:
#[error("Can't infer content type because `{}` does not have an extension. Please use a support extension (`.md`, `.rst`, `.txt`) or set the content type manually.", _0.user_display())]
MissingExtension(PathBuf),
#[error("Unsupported content type: `{0}`")]
#[error("Unsupported content type: {0}")]
UnsupportedContentType(String),
#[error("`project.description` must be a single line")]
DescriptionNewlines,
@ -51,23 +51,29 @@ pub enum ValidationError {
)]
MixedLicenseGenerations,
#[error(
"Entrypoint groups must consist of letters and numbers separated by dots, invalid group: `{0}`"
"Entrypoint groups must consist of letters and numbers separated by dots, invalid group: {0}"
)]
InvalidGroup(String),
#[error(
"Entrypoint names must consist of letters, numbers, dots, underscores and dashes; invalid name: `{0}`"
)]
InvalidName(String),
#[error("Use `project.scripts` instead of `project.entry-points.console_scripts`")]
ReservedScripts,
#[error("Use `project.gui-scripts` instead of `project.entry-points.gui_scripts`")]
ReservedGuiScripts,
#[error("`project.license` is not a valid SPDX expression: `{0}`")]
#[error("`project.license` is not a valid SPDX expression: {0}")]
@r###"`build_system.requires = ["uv_build"]` is missing an upper bound on the `uv_build` version such as `<0.5`. Without bounding the `uv_build` version, the source distribution will break when a future, breaking version of `uv_build` is released."###
Regex::new("ModuleNotFoundError: No module named ['\"]([^'\"]+)['\"]").unwrap()
});
/// e.g. `ModuleNotFoundError: No module named 'distutils'`
staticDISTUTILS_NOT_FOUND_RE: LazyLock<Regex>=
@ -90,6 +91,10 @@ pub enum Error {
NoSourceDistBuilds,
#[error("Cyclic build dependency detected for `{0}`")]
CyclicBuildDependency(PackageName),
#[error(
"Extra build requirement `{0}` was declared with `match-runtime = true`, but `{1}` does not declare static metadata, making runtime-matching impossible"
)]
UnmatchedRuntime(PackageName,PackageName),
}
implIsBuildBackendErrorforError{
@ -105,7 +110,8 @@ impl IsBuildBackendError for Error {
@ -190,29 +249,15 @@ impl Display for MissingHeaderCause {
iflet(Some(package_name),Some(package_version))=
(&self.package_name,&self.package_version)
{
write!(
hint_build_dependency(
f,
"This error likely indicates that `{}` depends on `{}`, but doesn't declare it as a build dependency. If `{}` is a first-party package, consider adding `{}` to its `{}`. Otherwise, `{}` into the environment and re-run with `{}`.",
"This error likely indicates that `{}` depends on `{}`, but doesn't declare it as a build dependency. If `{}` is a first-party package, consider adding `{}` to its `{}`. Otherwise, `{}` into the environment and re-run with `{}`.",
insta::assert_snapshot!(result,@"Unsupported hash algorithm (expected one of: `md5`, `sha256`, `sha384`, `sha512`, or `blake2b`) on: `blake2=6088930bfe239f0e6710546ab9c19c9ef35e29792895fed6e6e31a023a182a61`");