docs(src/assets/): update uv official documentation

KemingHe · github-actions[bot] · commit 2e95b57eb28a · 2025-10-21T22:06:22.000Z
diff --git a/src/assets/uv/_metadata.json b/src/assets/uv/_metadata.json
@@ -1,6 +1,6 @@
 {
   "source_repo": "astral-sh/uv",
   "docs_path": "docs",
-  "updated_at": "2025-10-14T22:05:43Z",
-  "commit_sha": "b151e0ea3d019ac733a9830466a6bf56b69087b2"
+  "updated_at": "2025-10-21T22:06:22Z",
+  "commit_sha": "0959763a828418410bdb7393696249b71e536969"
 }
diff --git a/src/assets/uv/concepts/build-backend.md b/src/assets/uv/concepts/build-backend.md
@@ -31,7 +31,7 @@ To use uv as a build backend in an existing project, add `uv_build` to the
 
 ```toml title="pyproject.toml"
 [build-system]
-requires = ["uv_build>=0.9.2,<0.10.0"]
+requires = ["uv_build>=0.9.5,<0.10.0"]
 build-backend = "uv_build"
 ```
 
diff --git a/src/assets/uv/concepts/projects/init.md b/src/assets/uv/concepts/projects/init.md
@@ -111,7 +111,7 @@ dependencies = []
 example-pkg = "example_pkg:main"
 
 [build-system]
-requires = ["uv_build>=0.9.2,<0.10.0"]
+requires = ["uv_build>=0.9.5,<0.10.0"]
 build-backend = "uv_build"
 ```
 
@@ -134,7 +134,7 @@ dependencies = []
 example-pkg = "example_pkg:main"
 
 [build-system]
-requires = ["uv_build>=0.9.2,<0.10.0"]
+requires = ["uv_build>=0.9.5,<0.10.0"]
 build-backend = "uv_build"
 ```
 
@@ -195,7 +195,7 @@ requires-python = ">=3.11"
 dependencies = []
 
 [build-system]
-requires = ["uv_build>=0.9.2,<0.10.0"]
+requires = ["uv_build>=0.9.5,<0.10.0"]
 build-backend = "uv_build"
 ```
 
diff --git a/src/assets/uv/concepts/projects/workspaces.md b/src/assets/uv/concepts/projects/workspaces.md
@@ -75,7 +75,7 @@ bird-feeder = { workspace = true }
 members = ["packages/*"]
 
 [build-system]
-requires = ["uv_build>=0.9.2,<0.10.0"]
+requires = ["uv_build>=0.9.5,<0.10.0"]
 build-backend = "uv_build"
 ```
 
@@ -106,7 +106,7 @@ tqdm = { git = "https://github.com/tqdm/tqdm" }
 members = ["packages/*"]
 
 [build-system]
-requires = ["uv_build>=0.9.2,<0.10.0"]
+requires = ["uv_build>=0.9.5,<0.10.0"]
 build-backend = "uv_build"
 ```
 
@@ -188,7 +188,7 @@ dependencies = ["bird-feeder", "tqdm>=4,<5"]
 bird-feeder = { path = "packages/bird-feeder" }
 
 [build-system]
-requires = ["uv_build>=0.9.2,<0.10.0"]
+requires = ["uv_build>=0.9.5,<0.10.0"]
 build-backend = "uv_build"
 ```
 
diff --git a/src/assets/uv/concepts/python-versions.md b/src/assets/uv/concepts/python-versions.md
@@ -444,7 +444,7 @@ As Python does not publish official distributable CPython binaries, uv instead u
 distributions from the Astral
 [`python-build-standalone`](https://github.com/astral-sh/python-build-standalone) project.
 `python-build-standalone` is also is used in many other Python projects, like
-[Rye](https://github.com/astral-sh/rye), [Mise](https://mise.jdx.dev/lang/python.html), and
+[Mise](https://mise.jdx.dev/lang/python.html) and
 [bazelbuild/rules_python](https://github.com/bazelbuild/rules_python).
 
 The uv Python distributions are self-contained, highly-portable, and performant. While Python can be
@@ -453,8 +453,7 @@ creating optimized, performant builds (e.g., with PGO and LTO enabled) is very s
 
 These distributions have some behavior quirks, generally as a consequence of portability; see the
 [`python-build-standalone` quirks](https://gregoryszorc.com/docs/python-build-standalone/main/quirks.html)
-documentation for details. Additionally, some platforms may not be supported (e.g., distributions
-are not yet available for musl Linux on ARM).
+documentation for details.
 
 ### PyPy distributions
 
diff --git a/src/assets/uv/getting-started/installation.md b/src/assets/uv/getting-started/installation.md
@@ -25,7 +25,7 @@ uv provides a standalone installer to download and install uv:
     Request a specific version by including it in the URL:
 
     ```console
-    $ curl -LsSf https://astral.sh/uv/0.9.2/install.sh | sh
+    $ curl -LsSf https://astral.sh/uv/0.9.5/install.sh | sh
     ```
 
 === "Windows"
@@ -41,7 +41,7 @@ uv provides a standalone installer to download and install uv:
     Request a specific version by including it in the URL:
 
     ```pwsh-session
-    PS> powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.9.2/install.ps1 | iex"
+    PS> powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.9.5/install.ps1 | iex"
     ```
 
 !!! tip
diff --git a/src/assets/uv/guides/integration/aws-lambda.md b/src/assets/uv/guides/integration/aws-lambda.md
@@ -92,7 +92,7 @@ the second stage, we'll copy this directory over to the final image, omitting th
 other unnecessary files.
 
 ```dockerfile title="Dockerfile"
-FROM ghcr.io/astral-sh/uv:0.9.2 AS uv
+FROM ghcr.io/astral-sh/uv:0.9.5 AS uv
 
 # First, bundle the dependencies into the task root.
 FROM public.ecr.aws/lambda/python:3.13 AS builder
@@ -334,7 +334,7 @@ And confirm that opening http://127.0.0.1:8000/ in a web browser displays, "Hell
 Finally, we'll update the Dockerfile to include the local library in the deployment package:
 
 ```dockerfile title="Dockerfile"
-FROM ghcr.io/astral-sh/uv:0.9.2 AS uv
+FROM ghcr.io/astral-sh/uv:0.9.5 AS uv
 
 # First, bundle the dependencies into the task root.
 FROM public.ecr.aws/lambda/python:3.13 AS builder
diff --git a/src/assets/uv/guides/integration/docker.md b/src/assets/uv/guides/integration/docker.md
@@ -31,7 +31,7 @@ $ docker run --rm -it ghcr.io/astral-sh/uv:debian uv --help
 The following distroless images are available:
 
 - `ghcr.io/astral-sh/uv:latest`
-- `ghcr.io/astral-sh/uv:{major}.{minor}.{patch}`, e.g., `ghcr.io/astral-sh/uv:0.9.2`
+- `ghcr.io/astral-sh/uv:{major}.{minor}.{patch}`, e.g., `ghcr.io/astral-sh/uv:0.9.5`
 - `ghcr.io/astral-sh/uv:{major}.{minor}`, e.g., `ghcr.io/astral-sh/uv:0.8` (the latest patch
   version)
 
@@ -95,7 +95,7 @@ And the following derived images are available:
 
 As with the distroless image, each derived image is published with uv version tags as
 `ghcr.io/astral-sh/uv:{major}.{minor}.{patch}-{base}` and
-`ghcr.io/astral-sh/uv:{major}.{minor}-{base}`, e.g., `ghcr.io/astral-sh/uv:0.9.2-alpine`.
+`ghcr.io/astral-sh/uv:{major}.{minor}-{base}`, e.g., `ghcr.io/astral-sh/uv:0.9.5-alpine`.
 
 In addition, starting with `0.8` each derived image also sets `UV_TOOL_BIN_DIR` to `/usr/local/bin`
 to allow `uv tool install` to work as expected with the default user.
@@ -136,7 +136,7 @@ Note this requires `curl` to be available.
 In either case, it is best practice to pin to a specific uv version, e.g., with:
 
 ```dockerfile
-COPY --from=ghcr.io/astral-sh/uv:0.9.2 /uv /uvx /bin/
+COPY --from=ghcr.io/astral-sh/uv:0.9.5 /uv /uvx /bin/
 ```
 
 !!! tip
@@ -154,7 +154,7 @@ COPY --from=ghcr.io/astral-sh/uv:0.9.2 /uv /uvx /bin/
 Or, with the installer:
 
 ```dockerfile
-ADD https://astral.sh/uv/0.9.2/install.sh /uv-installer.sh
+ADD https://astral.sh/uv/0.9.5/install.sh /uv-installer.sh
 ```
 
 ### Installing a project
@@ -590,5 +590,5 @@ Verified OK
 !!! tip
 
     These examples use `latest`, but best practice is to verify the attestation for a specific
-    version tag, e.g., `ghcr.io/astral-sh/uv:0.9.2`, or (even better) the specific image digest,
+    version tag, e.g., `ghcr.io/astral-sh/uv:0.9.5`, or (even better) the specific image digest,
     such as `ghcr.io/astral-sh/uv:0.5.27@sha256:5adf09a5a526f380237408032a9308000d14d5947eafa687ad6c6a2476787b4f`.
diff --git a/src/assets/uv/guides/integration/github.md b/src/assets/uv/guides/integration/github.md
@@ -47,7 +47,7 @@ jobs:
         uses: astral-sh/setup-uv@v6
         with:
           # Install a specific version of uv.
-          version: "0.9.2"
+          version: "0.9.5"
 ```
 
 ## Setting up Python
diff --git a/src/assets/uv/guides/integration/pre-commit.md b/src/assets/uv/guides/integration/pre-commit.md
@@ -19,7 +19,7 @@ To make sure your `uv.lock` file is up to date even if your `pyproject.toml` fil
 repos:
   - repo: https://github.com/astral-sh/uv-pre-commit
     # uv version.
-    rev: 0.9.2
+    rev: 0.9.5
     hooks:
       - id: uv-lock
 ```
@@ -30,7 +30,7 @@ To keep a `requirements.txt` file in sync with your `uv.lock` file:
 repos:
   - repo: https://github.com/astral-sh/uv-pre-commit
     # uv version.
-    rev: 0.9.2
+    rev: 0.9.5
     hooks:
       - id: uv-export
 ```
@@ -41,7 +41,7 @@ To compile requirements files:
 repos:
   - repo: https://github.com/astral-sh/uv-pre-commit
     # uv version.
-    rev: 0.9.2
+    rev: 0.9.5
     hooks:
       # Compile requirements
       - id: pip-compile
@@ -54,7 +54,7 @@ To compile alternative requirements files, modify `args` and `files`:
 repos:
   - repo: https://github.com/astral-sh/uv-pre-commit
     # uv version.
-    rev: 0.9.2
+    rev: 0.9.5
     hooks:
       # Compile requirements
       - id: pip-compile
@@ -68,7 +68,7 @@ To run the hook over multiple files at the same time, add additional entries:
 repos:
   - repo: https://github.com/astral-sh/uv-pre-commit
     # uv version.
-    rev: 0.9.2
+    rev: 0.9.5
     hooks:
       # Compile requirements
       - id: pip-compile
diff --git a/src/assets/uv/guides/integration/pytorch.md b/src/assets/uv/guides/integration/pytorch.md
@@ -460,12 +460,4 @@ $ # With an environment variable.
 $ UV_TORCH_BACKEND=cu126 uv pip install torch torchvision
 ```
 
-On Windows, Intel GPU (XPU) is not automatically selected with `--torch-backend=auto`, but you can
-manually specify it using `--torch-backend=xpu`:
-
-```shell
-$ # Manual selection for Intel GPU.
-$ uv pip install torch torchvision --torch-backend=xpu
-```
-
 At present, `--torch-backend` is only available in the `uv pip` interface.
diff --git a/src/assets/uv/reference/cli.md b/src/assets/uv/reference/cli.md
@@ -1634,7 +1634,7 @@ uv lock [OPTIONS]
 <p>May also be set with the <code>UV_INSECURE_HOST</code> environment variable.</p></dd><dt id="uv-lock--cache-dir"><a href="#uv-lock--cache-dir"><code>--cache-dir</code></a> <i>cache-dir</i></dt><dd><p>Path to the cache directory.</p>
 <p>Defaults to <code>$XDG_CACHE_HOME/uv</code> or <code>$HOME/.cache/uv</code> on macOS and Linux, and <code>%LOCALAPPDATA%\uv\cache</code> on Windows.</p>
 <p>To view the location of the cache directory, run <code>uv cache dir</code>.</p>
-<p>May also be set with the <code>UV_CACHE_DIR</code> environment variable.</p></dd><dt id="uv-lock--check"><a href="#uv-lock--check"><code>--check</code></a>, <code>--locked</code></dt><dd><p>Check if the lockfile is up-to-date.</p>
+<p>May also be set with the <code>UV_CACHE_DIR</code> environment variable.</p></dd><dt id="uv-lock--check"><a href="#uv-lock--check"><code>--check</code></a></dt><dd><p>Check if the lockfile is up-to-date.</p>
 <p>Asserts that the <code>uv.lock</code> would remain unchanged after a resolution. If the lockfile is missing or needs to be updated, uv will exit with an error.</p>
 <p>Equivalent to <code>--locked</code>.</p>
 <p>May also be set with the <code>UV_LOCKED</code> environment variable.</p></dd><dt id="uv-lock--check-exists"><a href="#uv-lock--check-exists"><code>--check-exists</code></a>, <code>--frozen</code></dt><dd><p>Assert that a <code>uv.lock</code> exists without checking if it is up-to-date.</p>
@@ -4254,6 +4254,7 @@ by <code>--python-version</code>.</p>
 <ul>
 <li><code>auto</code>:  Select the appropriate PyTorch index based on the operating system and CUDA driver version</li>
 <li><code>cpu</code>:  Use the CPU-only PyTorch index</li>
+<li><code>cu130</code>:  Use the PyTorch index for CUDA 13.0</li>
 <li><code>cu129</code>:  Use the PyTorch index for CUDA 12.9</li>
 <li><code>cu128</code>:  Use the PyTorch index for CUDA 12.8</li>
 <li><code>cu126</code>:  Use the PyTorch index for CUDA 12.6</li>
@@ -4536,6 +4537,7 @@ be used with caution, as it can modify the system Python installation.</p>
 <ul>
 <li><code>auto</code>:  Select the appropriate PyTorch index based on the operating system and CUDA driver version</li>
 <li><code>cpu</code>:  Use the CPU-only PyTorch index</li>
+<li><code>cu130</code>:  Use the PyTorch index for CUDA 13.0</li>
 <li><code>cu129</code>:  Use the PyTorch index for CUDA 12.9</li>
 <li><code>cu128</code>:  Use the PyTorch index for CUDA 12.8</li>
 <li><code>cu126</code>:  Use the PyTorch index for CUDA 12.6</li>
@@ -4844,6 +4846,7 @@ should be used with caution, as it can modify the system Python installation.</p
 <ul>
 <li><code>auto</code>:  Select the appropriate PyTorch index based on the operating system and CUDA driver version</li>
 <li><code>cpu</code>:  Use the CPU-only PyTorch index</li>
+<li><code>cu130</code>:  Use the PyTorch index for CUDA 13.0</li>
 <li><code>cu129</code>:  Use the PyTorch index for CUDA 12.9</li>
 <li><code>cu128</code>:  Use the PyTorch index for CUDA 12.8</li>
 <li><code>cu126</code>:  Use the PyTorch index for CUDA 12.6</li>
diff --git a/src/assets/uv/reference/internals/resolver.md b/src/assets/uv/reference/internals/resolver.md
@@ -151,6 +151,58 @@ that use the local tag for different hardware accelerators such as torch. While
 mapping between wheel tags and markers, we can do a mapping for well-known platforms, including
 Windows, Linux and macOS.
 
+## Metadata consistency
+
+uv, similar to poetry, requires that wheels of a single version of a package in a specific index
+have the same dependencies (`Requires-Dist` in `METADATA`), including wheels build from a source
+distribution. More generally, uv assumes that each wheel has the same `METADATA` file in its
+dist-info directory.
+
+numpy 2.3.2 for example has 73 wheels. Without this assumption, uv would have to make 73 network
+requests to fetch its metadata, instead of a single one. Another problem we would have without
+metadata consistency is the lack of a 1:1 mapping between markers and wheel tags. Wheel tags can
+include the glibc version while the PEP 508 markers cannot represent it. If wheels had different
+metadata, a universal resolver would have to track two dimensions simultaneously, PEP 508 markers
+and wheel tags. This would increase complexity a lot, and the correspondence between the two is not
+properly specified. PEP 508 markers have been introduced specifically to allow different
+dependencies between different platform, i.e. to have a single dependency declaration for all
+wheels, such as `project.[optional-]dependencies`. If the markers are not sufficient, we should
+extend PEP 508 markers instead of using a parallel system of wheel tags.
+
+Another aspect of metadata consistency is that a source distribution must build into a wheel with
+the same metadata as the wheels, or if there are no wheels, into the same metadata each time. If
+this assumption is violated, sound dependency locking becomes impossible: Consider a package A has a
+source distribution. During resolution, we build A v1 and obtain the dependencies `B>=2,<3`. We lock
+`A==1` and `B==2`. When installing the lockfile on the target machine, we build again and obtain
+dependencies `B>=3,<4` and `C>=1,<2`. The lockfile fails to install: Due to the changed constraints,
+the locked version of `B` is incompatible, and there's no locked candidate for `C`. Re-resolving
+after this would both be a reproducibility problem (the lockfile is effectively ignored) and a
+security concern (`C` has not been reviewed, neither was `B==3`). It's possible to fail on
+installation if that happens, but a late error, possibly during deployment, is a bad user
+experience. There is already a case where uv fails on installation, packages with no source
+distribution and only platform specific wheels incompatible with the current platform. While uv has
+[required environments](https://docs.astral.sh/uv/concepts/resolution/#required-environments) as
+mitigation, this requires a not well known configuration option, and questions around (un)supported
+environments are one of the most common problem for uv users. A similar situation with source
+distributions should be avoided.
+
+While older versions of torch and tensorflow had inconsistent metadata, all recent versions have
+consistent metadata, and we are not aware of any major package with inconsistent metadata. There is
+however no requirement in the Python packaging standards that metadata must be consistent, and
+requests to enforce this in the standards have been rejected
+(https://discuss.python.org/t/enforcing-consistent-metadata-for-packages/50008).
+
+There are packages that have native code that links against the native code in another package, such
+as torch. These package may support building against a range of torch versions, but once built, they
+are constrained to a specific torch version, and the runtime torch version must match the build-time
+version. These are currently a pain point across all package managers, as all major package managers
+from pip to uv cache source distribution builds. uv supports multiple builds depending on the
+version of the already installed package using
+[ `tool.uv.extra-build-dependencies`](https://docs.astral.sh/uv/concepts/projects/config/#augmenting-build-dependencies)
+with `match-runtime = true`. This is a workaround that needs to be made on the user side for each
+affected package, instead of library developers declaring this requirement, which would be possible
+with native standards support.
+
 ## Requires-python
 
 To ensure that a resolution with `requires-python = ">=3.9"` can actually be installed for the

Original file line number	Diff line number	Diff line change
`@@ -1,6 +1,6 @@`
`1`	`1`	`{`
`2`	`2`	`"source_repo": "astral-sh/uv",`
`3`	`3`	`"docs_path": "docs",`
`4`		`- "updated_at": "2025-10-14T22:05:43Z",`
`5`		`- "commit_sha": "b151e0ea3d019ac733a9830466a6bf56b69087b2"`
	`4`	`+ "updated_at": "2025-10-21T22:06:22Z",`
	`5`	`+ "commit_sha": "0959763a828418410bdb7393696249b71e536969"`
`6`	`6`	`}`