Previously, we had a retry count both on the top level error type, and
on an error variant, and had a conversion step in between. When
reviewing #17274, I noticed we can simplify that.
## Summary
Fixes#17266.
The retry count was getting dropped by
`ErrorKind::from_retry_middleware` and `<Error as
From<ErrorKind>>::from` so we were doing more retries than we should
have.
## Test Plan
Added a testcase for the specific error path in the issue. Added an
expect to the other retry test too.
## Summary
Gates four tests in `python_find.rs` that call `python_install()` behind
the `python-managed` feature flag. These tests attempt to download
Python versions from the network (free-threaded and pre-release
versions) which fail in offline build environments.
Fixes#16431
## Test Plan
Verified that the gated tests match the pattern used elsewhere in the
codebase where the entire `python_install` module is already gated
behind `#[cfg(feature = "python-managed")]`.
Since #16923, `-` stdin paths are suddenly only supported on the
`RequirementsSource::Extensionless`. However, parsing of cli arguments
using `from_requirements_txt`, `from_constraints_txt`
`from_overrides_txt` would always output a
`RequirementsSource::RequirementsTxt`. Resulting in the error:
```
$ cat overrides.txt | cargo run --bin uv --profile dev --manifest-path ./uv/crates/uv/Cargo.toml pip install 'numpy' --overrides=-
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.22s
Running `./uv/target/debug/uv pip install 'numpy' --overrides=-`
error: File not found: `-`
```
In this PR, I've added a small check in those for the `-` paths to use
`RequirementsSource::ExtensionLess`.
I'm not too sure about this change though, as it would also implicitly
start allowing PEP 723 scripts as input to overrides/constraints. I
don't see the direct issue in that, but then maybe we should explicitly
handle it so that an `--overrides=script.py` would also be supported.
@zanieb what do you think?
Relates to #17227
## Summary
Partially address #16709.
Previously, if cornered, `pip compile` would fail when the requested
python interpreter couldn't be found (more details in the issue and
comments), and now in those cases it will download it.
## Test Plan
Added an integration test for this case.
This also removes the file-specific targets from prettier execution
which means we're including `.json`, `.css`, and `.html` files, which
seems like an improvement.
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Implement #16653 by making `uv sync --output-format=json` output
information about package changes.
## Test Plan
Additional tests to test the cases where there is no known package
version _may_ be beneficial but as the information used is the same as
the information used by the dry run logging now, I don't think that's
strictly necessary as those cases are tested.
---------
Co-authored-by: Liam <liam@scalzulli.com>
We were using slightly different retry code in multiple places, this PR
unifies it.
Also fixes retry undercounting in publish if the retry middleware was
involved.
---------
Co-authored-by: Tomasz 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
improve code comments clarity
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
Signed-off-by: stringscut <stringscut@outlook.jp>
## 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.
