Add an experimental JSON format for METADATA and WHEEL files in the uv build backend to have a reference what it would look like and to demonstrate that the actual change is just a few lines, how much easier it is than the existing email-ish format.
## Summary
Right now, when we return a `Dist` from a lockfile, we concatenate all
hashes for all distributions for a given package. In the case of
https://github.com/astral-sh/uv/issues/17143, I think that means we'll
return the SHA256 from the sdist, plus the SHA512 from the wheel. If the
wheel was previously installed (i.e., it's in the cache), and we
computed the SHA256 at that point in time, then `Hashed::has_digests`
would return `true` because we have _at least_ one SHA256. We now limit
the hashes to the distribution that we expect to install.
Closes https://github.com/astral-sh/uv/issues/17143.
<!--
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
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.
* 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
## 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>
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? -->
## 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.
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.
Charlie Marsh
konsti
jkipper
Diyor Khayrutdinov
Tomasz Kramkowski
samypr100
haruna
Matthew Mckee
Mathieu Kniewallner
Eashwar Ranganathan
Zanie Blue
Ben Beasley
github-actions[bot]
F4RAN
chisato
Zsolt Dollenstein
liam