## 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.
## 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.
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>
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
#12175 changed the behavior of `on_request_complete` when stderr is not
a tty to output `Downloading`/`Uploading` (via `Direction::as_str`).
This fixes it to output `Downloaded`/`Uploaded` again.
## Test Plan
Tested locally to verify new output.
Old:
```
$ uv sync --no-cache 2>&1 | tee /dev/null
Using CPython 3.14.0
Creating virtual environment at: .venv
Resolved 12 packages in 19ms
Downloading numpy (15.8MiB)
Downloading matplotlib (9.4MiB)
Downloading fonttools (4.6MiB)
Downloading pillow (6.7MiB)
Downloading kiwisolver (1.4MiB)
Downloading kiwisolver
Downloading fonttools
Downloading pillow
Downloading matplotlib
Downloading numpy
```
New:
```
$ uv sync --no-cache 2>&1 | tee /dev/null
Using CPython 3.14.0
Creating virtual environment at: .venv
Resolved 12 packages in 3ms
Downloading numpy (15.8MiB)
Downloading fonttools (4.6MiB)
Downloading matplotlib (9.4MiB)
Downloading kiwisolver (1.4MiB)
Downloading pillow (6.7MiB)
Downloaded kiwisolver
Downloaded pillow
Downloaded fonttools
Downloaded matplotlib
Downloaded numpy
```
Dependabot appears to run a proxy which intercepts all requests and adds
credentials — credentials are _not_ provided via the CLI or environment
variables and there's no way for a user to do so. This means that when
`authenticate = "always"` is used (or when the index URL is on a pyx
domain), uv will fail even though Dependabot may intercept the request
and add credentials.
See
https://github.com/dependabot/dependabot-core/#private-registry-credential-management
I'm a little wary here, in the sense that it might be silly to have a
command that does something so simple that's covered by `uv workspace
metadata`? but I think this could be stabilized much faster than `uv
workspace metadata` and makes it easier to write scripts against
workspace members.
---------
Co-authored-by: liam <liam@scalzulli.com>
Resolves https://github.com/astral-sh/uv/issues/16693
[`PEP 639`](https://peps.python.org/pep-0639/#add-license-files-key)
requires build tools to error if any user-specified
`project.license-files` glob fails to match a file, but uv currently
allows the build to succeed and produces empty `.dist-info/licenses/`
directories.
This PR enforces the spec by tracking matches for each glob during
metadata generation, raising a clear
validation error when one is unmatched.
This allows us to suggest `uv python install --upgrade 3.14` as the
canonical way to get the latest patch version of a given Python
regardless of whether it is installed already. Currently, you can do `uv
python upgrade 3.14` and it will install it, but I'd like to remove that
behavior as I find it very surprising.
Charlie Marsh
samypr100
Zanie Blue
Tomasz Kramkowski
Zsolt Dollenstein
Sidharth Anil
Ben Berry-Allwood
Nicola Soranzo
William Woodruff
konsti
liam
github-actions[bot]
Tom Schafer
Ryan Blue
Meitar Reihan