## Summary
Follow up to
https://github.com/astral-sh/uv/pull/15269#issuecomment-3194000772
Enables the following additional images to be published
* buildpack-deps:trixie
* debian:trixie-slim
* alpine:3.22
## Test Plan
Existing Tests. The newly added images were checked manually.
I updated the Github Actions integration guide to run Github's
`setup-python` before Astral's `setup-uv`, as `setup-uv`'s
`activate-environment: true` doesn't work with the original ordering.
There is a discussion about this behavior in the `setup-uv` repo
[here](https://github.com/astral-sh/setup-uv/issues/479).
<!--
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 documentation for the Github Actions integration. Caveat: I'm
unsure if there are any other reasons where the original ordering (that
is,`setup-uv` before `setup-python`) might be preferred.
## Test Plan
Tested in a private Github Actions push, as documented in the
aforementioned discussion on `setup-uv`'s repo. Confirmed that removing
`source .venv/bin/activate` and replacing it with `activate-environment:
true` now works in this ordering (but didn't work with the original
ordering where `uv` installs before Github's `python`).
Closes#13057
Sets `UV_TOOL_BIN_DIR` to `/usr/local/bin` for all derived images to
allow `uv tool install` to work out of the box.
Note, when the default image user is overwritten (e.g. `USER <UID>`) by
a less privileged one, an alternative writable location would now need
to be set by downstream consumers to prevent issues, hence I'm labeling
this as a breaking change for 0.8.x release.
Relates to https://github.com/astral-sh/uv-docker-example/pull/55
Each image was tested to work with uv tool with `UV_TOOL_BIN_DIR` set to
`/usr/local/bin` with the default root user and alternative non-root
users to confirm breaking nature of the change.
## Summary
This PR intends to enable `--torch-backend=auto` to detect Intel GPUs
automatically:
- On Linux, detection is performed using the `lspci` command via
`Display controller` id.
- On Windows, ~~detection is done via a `powershell` query to
`Win32_VideoController`~~. Skip support for now—revisit once a better
solution is available.
Currently, Intel GPUs (XPU) do not rely on specific driver or toolkit
versions to distribute different PyTorch wheels.
## Test Plan
<!-- How was it tested? -->
On Linux:

~~On Windows:
~~
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
Allows `--torch-backend=auto` to detect AMD GPUs. The approach is fairly
well-documented inline, but I opted for `rocm_agent_enumerator` over
(e.g.) `rocminfo` since it seems to be the recommended approach for
scripting:
https://rocm.docs.amd.com/projects/rocminfo/en/latest/how-to/use-rocm-agent-enumerator.html.
Closes https://github.com/astral-sh/uv/issues/14086.
## Test Plan
```
root@rocm-jupyter-gpu-mi300x1-192gb-devcloud-atl1:~# ./uv-linux-libc-11fb582c5c046bae09766ceddd276dcc5bb41218/uv pip install torch --torch-backend=auto
Resolved 11 packages in 251ms
Prepared 2 packages in 6ms
Installed 11 packages in 257ms
+ filelock==3.18.0
+ fsspec==2025.5.1
+ jinja2==3.1.6
+ markupsafe==3.0.2
+ mpmath==1.3.0
+ networkx==3.5
+ pytorch-triton-rocm==3.3.1
+ setuptools==80.9.0
+ sympy==1.14.0
+ torch==2.7.1+rocm6.3
+ typing-extensions==4.14.0
```
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Replace wrong `cuda124` version to the correct `cuda128` version in
torch docs
## Test Plan
<!-- How was it tested? -->
<!--
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
I follow the advices from the IDE spell checker and grammar checker, fix
some typos, and improve the docs.
Extends https://github.com/astral-sh/uv/pull/13841 — I'll drop that
commit later after that pull request merges but it's small.
I find the split into a "Configuration" section awkward and don't think
it's helping us. Everything moved into the "Concepts" section, except
the "Environment variables" page which definitely belongs in the
reference and the "Installer" page which is fairly niche and seems
better in the reference.
Before / After
<img
src="https://github.com/user-attachments/assets/80d8304b-17da-4900-a5f4-c3ccac96fcc5"
width="400">
<!--
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
This change adds a new integration guide, on using uv with marimo
notebooks. It is similar to but simpler than the existing Jupyter guide,
since marimo stores notebooks as Python files and also integrates
tightly with uv for package management.
The guide showcases four ways of using uv with marimo:
1. marimo as a standalone tool (`uvx`)
2. managing inline script metadata (an alternative to Jupyter kernels,
marimo has no concept of kernels)
3. in project environments
4. in non-project environments
## Test Plan
N/A as this is a docs-only change.
---------
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
When creating the `.pre-commit-config.yaml` from scratch, although
following https://pre-commit.com/, it might be easy to overlook that the
pre-commit repo examples need to be added below the `repos` list item to
get a valid `yaml` file.
Additionally, updated the version of the first two examples.
## Test Plan
I followed the `CONTRIBUTING.md` and the result looked fine.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>