<!--
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
@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."###
insta::assert_snapshot!(result,@"Unsupported hash algorithm (expected one of: `md5`, `sha256`, `sha384`, `sha512`, or `blake2b`) on: `blake2=6088930bfe239f0e6710546ab9c19c9ef35e29792895fed6e6e31a023a182a61`");
Charlie Marsh
Zanie Blue
konsti
jkipper
Diyor Khayrutdinov
Tomasz Kramkowski
samypr100
Ben Beasley
haruna
Matthew Mckee
Mathieu Kniewallner
Eashwar Ranganathan
github-actions[bot]
William Woodruff
Niko Pikall
F4RAN
chisato
Zsolt Dollenstein
liam
Oshadha Gunawardena
Matthijs Kok
Matthew Woolf
renovate[bot]
Sidharth Anil
Ben Berry-Allwood
my1e5
Nicola Soranzo
Tom Schafer
pythonweb2
Ryan Blue
Meitar Reihan
CatBraaain
Mikayla Thompson
bigmoonbit
jspablo
Pavel Logan Dikov
Haaris Rahman
Les Freire
Michael Richter
Gabe Joseph
Blair Allan
Christian Asch
Aria Desires
Alexander Vandenbulcke
Clemens Brunner
twilligon
Hugo van Kemenade
elle
Basil Sh.
SADIK KUZU
Brian Dentino
Charles-Meldhine Madi Mnemoi
Samuel Rigaud
Jordan Borean
Andrei Berenda
eun2ce
Parham MohammadAlizadeh
Björn Dahlgren
David Peter
Yu, Guangye
Mark Dodgson
Mark Dodgson
Geoffrey Thomas
Harshith VH
Skyler Hawthorne
Alyssa Coghlan
Assad Yousuf
Mitchell Berendhuysen
tison
Shunsuke Tsuchiya
Ruben Arts
Samuel Dion-Girardeau
chance
Kevin Neal
Takayuki Maeda
Charles