uv tool

运行和安装由 Python 包提供的命令

用法

uv tool [OPTIONS] <COMMAND>

命令

uv tool run: 运行由 Python 包提供的命令
uv tool install: 安装由 Python 包提供的命令
uv tool upgrade: 升级已安装的工具
uv tool list: 列出已安装的工具
uv tool uninstall: 卸载工具
uv tool update-shell: 确保工具可执行文件目录在 PATH 中
uv tool dir: 显示 uv 工具目录的路径

uv tool run

运行由 Python 包提供的命令。

默认情况下，要安装的包名称假定与命令名称相同。

命令名称可以包含精确版本，格式为 <package>@<version>，例如 uv tool run ruff@0.3.0。如果需要更复杂的版本指定，或者命令由其他包提供，请使用 --from。

uvx 可用于调用 Python，例如通过 uvx python 或 uvx python@<version>。Python 解释器将在隔离的虚拟环境中启动。

如果该工具之前已安装（即通过 uv tool install），则将使用已安装的版本，除非请求了特定版本或使用了 --isolated 标志。

uvx 是 uv tool run 的便捷别名，其行为完全相同。

如果未提供命令，则显示已安装的工具。

包会被安装到 uv 缓存目录中的一个临时虚拟环境中。

用法

uv tool run [OPTIONS] [COMMAND]

选项

--allow-insecure-host, --trusted-host allow-insecure-host

允许连接到不安全的主机。

可以多次提供。

期望接收主机名（例如 localhost）、主机-端口对（例如 localhost:8080）或 URL（例如 https://localhost）。

警告：此列表中的主机将不会根据系统的证书存储进行验证。仅在具有已验证来源的安全网络中使用 --allow-insecure-host，因为它会绕过 SSL 验证，可能使您面临中间人攻击（MITM）的风险。

也可以通过 UV_INSECURE_HOST 环境变量设置。

--build-constraints, --build-constraint, -b build-constraints

在构建源码分发包时，使用给定的 requirements 文件约束构建依赖项。

约束文件是类似 requirements.txt 的文件，仅控制所安装依赖项的版本。但是，在约束文件中包含某个包不会触发该包的安装。

也可以通过 UV_BUILD_CONSTRAINT 环境变量设置。

--cache-dir cache-dir

缓存目录的路径。

在 macOS 和 Linux 上默认为 $XDG_CACHE_HOME/uv 或 $HOME/.cache/uv，在 Windows 上为 %LOCALAPPDATA%\uv\cache。

要查看缓存目录的位置，请运行 uv cache dir。

也可以通过 UV_CACHE_DIR 环境变量设置。

--color color-choice

控制输出中颜色的使用。

默认情况下，uv 会在写入终端时自动检测是否支持颜色。

可能的值：

auto：仅当输出到支持颜色的终端或 TTY 时启用彩色输出
always：无论检测到的环境如何，始终启用彩色输出
never：禁用彩色输出

--compile-bytecode, --compile

安装后将 Python 文件编译为字节码。

默认情况下，uv 不会将 Python（.py）文件编译为字节码（__pycache__/*.pyc）；相反，编译会在首次导入模块时延迟执行。对于启动时间至关重要的用例（如 CLI 应用程序和 Docker 容器），可以启用此选项，以较长的安装时间换取更快的启动时间。

启用后，uv 将处理整个 site-packages 目录（包括当前操作未修改的包）以保持一致性。与 pip 类似，它也会忽略错误。

也可以通过 UV_COMPILE_BYTECODE 环境变量设置。

--config-file config-file

用于配置的 uv.toml 文件路径。

虽然 uv 配置可以包含在 pyproject.toml 文件中，但在此上下文中不允许使用。

也可以通过 UV_CONFIG_FILE 环境变量设置。

--config-setting, --config-settings, -C config-setting

传递给 PEP 517 构建后端的设置，以 KEY=VALUE 对的形式指定

--config-settings-package, --config-settings-package config-settings-package

为特定包传递给 PEP 517 构建后端的设置，以 PACKAGE:KEY=VALUE 对的形式指定

--constraints, --constraint, -c constraints

使用给定的 requirements 文件约束版本。

约束文件是类似 requirements.txt 的文件，仅控制所安装依赖项的版本。但是，在约束文件中包含某个包不会触发该包的安装。

这等同于 pip 的 --constraint 选项。

也可以通过 UV_CONSTRAINT 环境变量设置。

--default-index default-index

默认包索引的 URL（默认为 https://pypi.org/simple）。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

此标志指定的索引优先级低于通过 --index 标志指定的所有其他索引。

也可以通过 UV_DEFAULT_INDEX 环境变量设置。

--directory directory

在运行命令之前切换到给定目录。

相对路径以给定目录为基准进行解析。

参见 --project 以仅更改项目根目录。

也可以通过 UV_WORKING_DIR 环境变量设置。

--env-file env-file

从 .env 文件加载环境变量。

可以多次提供，后续文件会覆盖先前文件中定义的值。

也可以通过 UV_ENV_FILE 环境变量设置。

--exclude-newer exclude-newer

将候选包限制为在给定日期之前上传的版本。

日期与每个分发包构件的上传时间（即每个文件上传到包索引的时间）进行比较，而非包版本的发布日期。

接受 RFC 3339 时间戳（例如 2006-12-02T02:07:43Z）、基于系统配置时区解析的相同格式的本地日期（例如 2006-12-02）、"友好"持续时间（例如 24 hours、1 week、30 days）或 ISO 8601 持续时间（例如 PT24H、P7D、P30D）。

持续时间不考虑本地时区的语义，始终解析为固定的秒数，假设一天为 24 小时（例如，忽略夏令时转换）。不允许使用月份和年份等日历单位。

也可以通过 UV_EXCLUDE_NEWER 环境变量设置。

--exclude-newer-package exclude-newer-package

将特定包的候选包限制为在给定日期之前上传的版本。

接受 PACKAGE=DATE 格式的包-日期对，其中 DATE 是 RFC 3339 时间戳（例如 2006-12-02T02:07:43Z）、基于系统配置时区解析的相同格式的本地日期（例如 2006-12-02）、"友好"持续时间（例如 24 hours、1 week、30 days）或 ISO 8601 持续时间（例如 PT24H、P7D、P30D）。

持续时间不考虑本地时区的语义，始终解析为固定的秒数，假设一天为 24 小时（例如，忽略夏令时转换）。不允许使用月份和年份等日历单位。

可以为不同的包多次提供。

--extra-index-url extra-index-url

（已弃用：请改用 --index）除 --index-url 之外，要使用的额外包索引 URL。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

通过此标志提供的所有索引优先级高于 --index-url（默认为 PyPI）指定的索引。当提供多个 --extra-index-url 标志时，较早的值优先。

也可以通过 UV_EXTRA_INDEX_URL 环境变量设置。

--find-links, -f find-links

除注册表索引中找到的分发包外，还要搜索候选分发包的位置。

如果是路径，目标必须是一个目录，其中包含顶层 wheel 文件（.whl）或源码分发包（例如 .tar.gz 或 .zip）。

如果是 URL，页面必须包含指向符合上述格式的包文件的扁平链接列表。

也可以通过 UV_FIND_LINKS 环境变量设置。

--fork-strategy fork-strategy

在跨 Python 版本和平台为给定包选择多个版本时使用的策略。

默认情况下，uv 会优化为每个支持的 Python 版本（requires-python）选择每个包的最新版本，同时最小化跨平台选择的版本数量。

在 fewest 策略下，uv 将最小化每个包选择的版本数量，优先选择与更广泛支持的 Python 版本或平台兼容的旧版本。

也可以通过 UV_FORK_STRATEGY 环境变量设置。

可能的值：

fewest：优化为每个包选择最少数量的版本。如果旧版本与更广泛支持的 Python 版本或平台兼容，则可能优先选择旧版本
requires-python：为每个支持的 Python 版本优化选择每个包的最新支持版本

--from from

使用给定的包来提供命令。

默认情况下，包名称假定与命令名称匹配。

--help, -h

显示此命令的简要帮助

--index index

解析依赖项时使用的 URL，除默认索引之外。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

通过此标志提供的所有索引优先级高于 --default-index（默认为 PyPI）指定的索引。当提供多个 --index 标志时，较早的值优先。

不支持索引名称作为值。相对路径必须通过 ./ 或 ../（Unix）或 .\\、..\\、./ 或 ../（Windows）与索引名称区分开来。

也可以通过 UV_INDEX 环境变量设置。

--index-strategy index-strategy

针对多个索引 URL 进行解析时使用的策略。

默认情况下，uv 会在第一个找到给定包的索引处停止，并将解析限制为该第一个索引上存在的版本（first-index）。这可以防止"依赖混淆"攻击，即攻击者可以在备用索引上以相同名称上传恶意包。

也可以通过 UV_INDEX_STRATEGY 环境变量设置。

可能的值：

first-index：仅使用第一个返回给定包名匹配结果的索引
unsafe-first-match：在所有索引中搜索每个包名，先穷尽第一个索引的版本，然后再转到下一个
unsafe-best-match：在所有索引中搜索每个包名，优先选择找到的"最佳"版本。如果一个包版本存在于多个索引中，则只查看第一个索引的条目

--index-url, -i index-url

（已弃用：请改用 --default-index）Python 包索引的 URL（默认为 https://pypi.org/simple）。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

此标志指定的索引优先级低于通过 --extra-index-url 标志指定的所有其他索引。

也可以通过 UV_INDEX_URL 环境变量设置。

--isolated

在隔离的虚拟环境中运行工具，忽略任何已安装的工具 [env: UV_ISOLATED=]

--keyring-provider keyring-provider

尝试使用 keyring 进行索引 URL 的身份验证。

目前仅支持 --keyring-provider subprocess，它配置 uv 使用 keyring CLI 来处理身份验证。

默认为 disabled。

也可以通过 UV_KEYRING_PROVIDER 环境变量设置。

可能的值：

disabled：不使用 keyring 进行凭据查找
subprocess：使用 keyring 命令进行凭据查找

--lfs

从 Git 添加依赖项时是否使用 Git LFS

--link-mode link-mode

从全局缓存安装包时使用的方法。

在 macOS 和 Linux 上默认为 clone（也称为写时复制），在 Windows 上默认为 hardlink。

警告：不鼓励使用 symlink 链接模式，因为它会在缓存和目标环境之间创建紧密耦合。例如，清除缓存（uv cache clean）将通过删除底层源文件来破坏所有已安装的包。请谨慎使用符号链接。

也可以通过 UV_LINK_MODE 环境变量设置。

可能的值：

clone：将包从源克隆（即写时复制）到目标
copy：将包从源复制到目标
hardlink：将包从源硬链接到目标
symlink：将包从源符号链接到目标

--managed-python

要求使用 uv 管理的 Python 版本 [env: UV_MANAGED_PYTHON=]

默认情况下，uv 优先使用它管理的 Python 版本。但是，如果未安装 uv 管理的 Python，它将使用系统 Python 版本。此选项禁用系统 Python 版本的使用。

--no-binary

不安装预编译的 wheel。

给定的包将从源码构建和安装。解析器仍将使用预编译的 wheel 来提取包元数据（如果可用）。

也可以通过 UV_NO_BINARY 环境变量设置。

--no-binary-package no-binary-package

不为特定包安装预编译的 wheel [env: UV_NO_BINARY_PACKAGE=]

--no-build

不构建源码分发包。

启用后，解析将不会运行任意 Python 代码。已构建的源码分发包的缓存 wheel 将被重用，但需要构建分发包的操作将退出并报错。

也可以通过 UV_NO_BUILD 环境变量设置。

--no-build-isolation

构建源码分发包时禁用隔离。

假定 PEP 518 指定的构建依赖项已安装。

也可以通过 UV_NO_BUILD_ISOLATION 环境变量设置。

--no-build-isolation-package no-build-isolation-package

为特定包构建源码分发包时禁用隔离。

假定该包的 PEP 518 构建依赖项已安装。

--no-build-package no-build-package

不为特定包构建源码分发包 [env: UV_NO_BUILD_PACKAGE=]

--no-cache, --no-cache-dir, -n

避免读取或写入缓存，在操作期间改用临时目录

也可以通过 UV_NO_CACHE 环境变量设置。

--no-config

避免发现配置文件（pyproject.toml、uv.toml）。

正常情况下，配置文件会在当前目录、父目录或用户配置目录中被发现。

也可以通过 UV_NO_CONFIG 环境变量设置。

--no-env-file

避免从 .env 文件读取环境变量 [env: UV_NO_ENV_FILE=]

--no-index

忽略注册表索引（例如 PyPI），转而依赖直接 URL 依赖项和通过 --find-links 提供的依赖项

--no-managed-python

禁用 uv 管理的 Python 版本 [env: UV_NO_MANAGED_PYTHON=]

相反，uv 将在系统上搜索合适的 Python 版本。

--no-progress

隐藏所有进度输出 [env: UV_NO_PROGRESS=]

例如，旋转指示器或进度条。

--no-python-downloads

禁用 Python 的自动下载。

--no-sources

解析依赖项时忽略 tool.uv.sources 表。用于根据符合标准、可发布的包元数据进行锁定，而不是使用任何工作区、Git、URL 或本地路径源

也可以通过 UV_NO_SOURCES 环境变量设置。

--no-sources-package no-sources-package

不为指定包使用 tool.uv.sources 表中的源 [env: UV_NO_SOURCES_PACKAGE=]

--offline

禁用网络访问 [env: UV_OFFLINE=]

禁用后，uv 将仅使用本地缓存数据和本地可用文件。

--overrides, --override overrides

使用给定的 requirements 文件覆盖版本。

覆盖文件是类似 requirements.txt 的文件，强制安装特定版本的需求，无论任何组成包声明了什么需求，也无论这是否会被视为无效的解析。

约束是附加性的，即它们与组成包的需求相结合；而覆盖是绝对性的，即它们完全替换组成包的需求。

也可以通过 UV_OVERRIDE 环境变量设置。

--prerelease prerelease

考虑预发布版本时使用的策略。

默认情况下，uv 将接受仅发布预发布版本的包的预发布版本，以及声明的版本说明符中包含显式预发布标记的第一方依赖项（if-necessary-or-explicit）。

也可以通过 UV_PRERELEASE 环境变量设置。

可能的值：

disallow：禁止所有预发布版本
allow：允许所有预发布版本
if-necessary：如果包的所有版本都是预发布版本，则允许预发布版本
explicit：允许版本要求中包含显式预发布标记的第一方包的预发布版本
if-necessary-or-explicit：如果包的所有版本都是预发布版本，或者包在其版本要求中有显式预发布标记，则允许预发布版本

--project project

在给定目录中发现项目。

所有 pyproject.toml、uv.toml 和 .python-version 文件将通过从项目根目录向上遍历目录树来发现，项目的虚拟环境（.venv）也是如此。

其他命令行参数（如相对路径）将相对于当前工作目录进行解析。

参见 --directory 以完全更改工作目录。

此设置在 uv pip 接口中使用时无效。

也可以通过 UV_PROJECT 环境变量设置。

--python, -p python

用于构建运行环境的 Python 解释器。

有关 Python 发现和支持的请求格式的详细信息，请参见 uv python。

也可以通过 UV_PYTHON 环境变量设置。

--python-platform python-platform

应为其安装依赖项的平台。

表示为"目标三元组"，一个描述目标平台的字符串，包含其 CPU、供应商和操作系统名称，如 x86_64-unknown-linux-gnu 或 aarch64-apple-darwin。

当目标为 macOS（Darwin）时，默认最低版本为 13.0。使用 MACOSX_DEPLOYMENT_TARGET 指定不同的最低版本，例如 14.0。

当目标为 iOS 时，默认最低版本为 13.0。使用 IPHONEOS_DEPLOYMENT_TARGET 指定不同的最低版本，例如 14.0。

当目标为 Android 时，默认最低 Android API 级别为 24。使用 ANDROID_API_LEVEL 指定不同的最低版本，例如 26。

警告：指定后，uv 将选择与目标平台兼容的 wheel；因此，已安装的分发包可能与当前平台不兼容。相反，从源码构建的任何分发包可能与目标平台不兼容，因为它们将针对当前平台构建。--python-platform 选项适用于高级用例。

可能的值：

windows：x86_64-pc-windows-msvc 的别名，Windows 的默认目标
linux：x86_64-unknown-linux-gnu 的别名，Linux 的默认目标
macos：aarch64-apple-darwin 的别名，macOS 的默认目标
x86_64-pc-windows-msvc：64 位 x86 Windows 目标
aarch64-pc-windows-msvc：ARM64 Windows 目标
i686-pc-windows-msvc：32 位 x86 Windows 目标
x86_64-unknown-linux-gnu：x86 Linux 目标。等同于 x86_64-manylinux_2_28
aarch64-apple-darwin：基于 ARM 的 macOS 目标，如 Apple Silicon 设备所示
x86_64-apple-darwin：x86 macOS 目标
aarch64-unknown-linux-gnu：ARM64 Linux 目标。等同于 aarch64-manylinux_2_28
aarch64-unknown-linux-musl：ARM64 Linux 目标
x86_64-unknown-linux-musl：x86_64 Linux 目标
riscv64-unknown-linux：RISCV64 Linux 目标
x86_64-manylinux2014：manylinux2014 平台的 x86_64 目标。等同于 x86_64-manylinux_2_17
x86_64-manylinux_2_17：manylinux_2_17 平台的 x86_64 目标
x86_64-manylinux_2_28：manylinux_2_28 平台的 x86_64 目标
x86_64-manylinux_2_31：manylinux_2_31 平台的 x86_64 目标
x86_64-manylinux_2_32：manylinux_2_32 平台的 x86_64 目标
x86_64-manylinux_2_33：manylinux_2_33 平台的 x86_64 目标
x86_64-manylinux_2_34：manylinux_2_34 平台的 x86_64 目标
x86_64-manylinux_2_35：manylinux_2_35 平台的 x86_64 目标
x86_64-manylinux_2_36：manylinux_2_36 平台的 x86_64 目标
x86_64-manylinux_2_37：manylinux_2_37 平台的 x86_64 目标
x86_64-manylinux_2_38：manylinux_2_38 平台的 x86_64 目标
x86_64-manylinux_2_39：manylinux_2_39 平台的 x86_64 目标
x86_64-manylinux_2_40：manylinux_2_40 平台的 x86_64 目标
aarch64-manylinux2014：manylinux2014 平台的 ARM64 目标。等同于 aarch64-manylinux_2_17
aarch64-manylinux_2_17：manylinux_2_17 平台的 ARM64 目标
aarch64-manylinux_2_28：manylinux_2_28 平台的 ARM64 目标
aarch64-manylinux_2_31：manylinux_2_31 平台的 ARM64 目标
aarch64-manylinux_2_32：manylinux_2_32 平台的 ARM64 目标
aarch64-manylinux_2_33：manylinux_2_33 平台的 ARM64 目标
aarch64-manylinux_2_34：manylinux_2_34 平台的 ARM64 目标
aarch64-manylinux_2_35：manylinux_2_35 平台的 ARM64 目标
aarch64-manylinux_2_36：manylinux_2_36 平台的 ARM64 目标
aarch64-manylinux_2_37：manylinux_2_37 平台的 ARM64 目标
aarch64-manylinux_2_38：manylinux_2_38 平台的 ARM64 目标
aarch64-manylinux_2_39：manylinux_2_39 平台的 ARM64 目标
aarch64-manylinux_2_40：manylinux_2_40 平台的 ARM64 目标
aarch64-linux-android：ARM64 Android 目标
x86_64-linux-android：x86_64 Android 目标
wasm32-pyodide2024：使用 Pyodide 2024 平台的 wasm32 目标。适用于 Python 3.12。参见 https://pyodide.org/en/stable/development/abi/312.html
wasm32-pyodide2025：使用 Pyodide 2025 平台的 wasm32 目标。适用于 Python 3.13。参见 https://pyodide.org/en/stable/development/abi/313.html
arm64-apple-ios：iOS 设备的 ARM64 目标
arm64-apple-ios-simulator：iOS 模拟器的 ARM64 目标
x86_64-apple-ios-simulator：iOS 模拟器的 x86_64 目标

--quiet, -q

使用静默输出。

重复此选项，例如 -qq，将启用静默模式，uv 将不会向 stdout 写入任何输出。

--refresh

刷新所有缓存数据

--refresh-package refresh-package

刷新特定包的缓存数据

--reinstall, --force-reinstall

重新安装所有包，无论它们是否已安装。隐含 --refresh

--reinstall-package reinstall-package

重新安装特定包，无论它是否已安装。隐含 --refresh-package

--resolution resolution

在给定包的不同兼容版本之间进行选择时使用的策略。

默认情况下，uv 将使用每个包的最新兼容版本（highest）。

也可以通过 UV_RESOLUTION 环境变量设置。

可能的值：

highest：解析每个包的最高兼容版本
lowest：解析每个包的最低兼容版本
lowest-direct：解析任何直接依赖项的最低兼容版本，以及任何传递依赖项的最高兼容版本

--system-certs

是否从平台的原生证书存储加载 TLS 证书 [env: UV_SYSTEM_CERTS=]

默认情况下，uv 使用捆绑的 Mozilla 根证书，这提高了可移植性和性能（尤其是在 macOS 上）。

但是，在某些情况下，您可能希望使用平台的原生证书存储，特别是当您依赖系统证书存储中包含的企业信任根（例如，用于强制代理）时。

--torch-backend torch-backend

获取 PyTorch 生态系统中的包时使用的后端（例如 cpu、cu126 或 auto）

设置后，uv 将忽略 PyTorch 生态系统中包的已配置索引 URL，转而使用定义的后端。

例如，当设置为 cpu 时，uv 将使用仅 CPU 的 PyTorch 索引；当设置为 cu126 时，uv 将使用 CUDA 12.6 的 PyTorch 索引。

auto 模式将尝试根据当前安装的 CUDA 驱动程序检测适当的 PyTorch 索引。

此选项处于预览阶段，可能在任何未来版本中发生更改。

也可以通过 UV_TORCH_BACKEND 环境变量设置。

可能的值：

auto：根据操作系统和 CUDA 驱动程序版本选择适当的 PyTorch 索引
cpu：使用仅 CPU 的 PyTorch 索引
cu130：使用 CUDA 13.0 的 PyTorch 索引
cu129：使用 CUDA 12.9 的 PyTorch 索引
cu128：使用 CUDA 12.8 的 PyTorch 索引
cu126：使用 CUDA 12.6 的 PyTorch 索引
cu125：使用 CUDA 12.5 的 PyTorch 索引
cu124：使用 CUDA 12.4 的 PyTorch 索引
cu123：使用 CUDA 12.3 的 PyTorch 索引
cu122：使用 CUDA 12.2 的 PyTorch 索引
cu121：使用 CUDA 12.1 的 PyTorch 索引
cu120：使用 CUDA 12.0 的 PyTorch 索引
cu118：使用 CUDA 11.8 的 PyTorch 索引
cu117：使用 CUDA 11.7 的 PyTorch 索引
cu116：使用 CUDA 11.6 的 PyTorch 索引
cu115：使用 CUDA 11.5 的 PyTorch 索引
cu114：使用 CUDA 11.4 的 PyTorch 索引
cu113：使用 CUDA 11.3 的 PyTorch 索引
cu112：使用 CUDA 11.2 的 PyTorch 索引
cu111：使用 CUDA 11.1 的 PyTorch 索引
cu110：使用 CUDA 11.0 的 PyTorch 索引
cu102：使用 CUDA 10.2 的 PyTorch 索引
cu101：使用 CUDA 10.1 的 PyTorch 索引
cu100：使用 CUDA 10.0 的 PyTorch 索引
cu92：使用 CUDA 9.2 的 PyTorch 索引
cu91：使用 CUDA 9.1 的 PyTorch 索引
cu90：使用 CUDA 9.0 的 PyTorch 索引
cu80：使用 CUDA 8.0 的 PyTorch 索引
rocm7.2：使用 ROCm 7.2 的 PyTorch 索引
rocm7.1：使用 ROCm 7.1 的 PyTorch 索引
rocm7.0：使用 ROCm 7.0 的 PyTorch 索引
rocm6.4：使用 ROCm 6.4 的 PyTorch 索引
rocm6.3：使用 ROCm 6.3 的 PyTorch 索引
rocm6.2.4：使用 ROCm 6.2.4 的 PyTorch 索引
rocm6.2：使用 ROCm 6.2 的 PyTorch 索引
rocm6.1：使用 ROCm 6.1 的 PyTorch 索引
rocm6.0：使用 ROCm 6.0 的 PyTorch 索引
rocm5.7：使用 ROCm 5.7 的 PyTorch 索引
rocm5.6：使用 ROCm 5.6 的 PyTorch 索引
rocm5.5：使用 ROCm 5.5 的 PyTorch 索引
rocm5.4.2：使用 ROCm 5.4.2 的 PyTorch 索引
rocm5.4：使用 ROCm 5.4 的 PyTorch 索引
rocm5.3：使用 ROCm 5.3 的 PyTorch 索引
rocm5.2：使用 ROCm 5.2 的 PyTorch 索引
rocm5.1.1：使用 ROCm 5.1.1 的 PyTorch 索引
rocm4.2：使用 ROCm 4.2 的 PyTorch 索引
rocm4.1：使用 ROCm 4.1 的 PyTorch 索引
rocm4.0.1：使用 ROCm 4.0.1 的 PyTorch 索引
xpu：使用 Intel XPU 的 PyTorch 索引

--upgrade, -U

允许包升级，忽略任何现有输出文件中的固定版本。隐含 --refresh

--upgrade-group upgrade-group

允许依赖组中所有包的升级，忽略任何现有输出文件中的固定版本

--upgrade-package, -P upgrade-package

允许特定包的升级，忽略任何现有输出文件中的固定版本。隐含 --refresh-package

--verbose, -v

使用详细输出。

您可以使用 RUST_LOG 环境变量配置细粒度日志记录。（https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#directives）

--with, -w with

使用给定的已安装包运行

--with-editable with-editable

使用以可编辑模式安装的给定包运行

在项目中使用时，这些依赖项将在单独的临时环境中叠加在 uv 工具环境之上。这些依赖项允许与指定的依赖项冲突。

--with-requirements with-requirements

使用给定文件中列出的包运行。

支持以下格式：requirements.txt、带有内联元数据的 .py 文件和 pylock.toml。

uv tool install

安装由 Python 包提供的命令。

包会被安装到 uv 工具目录中的隔离虚拟环境。可执行文件被链接到工具可执行文件目录，该目录根据 XDG 标准确定，可以通过 uv tool dir --bin 获取。

如果该工具之前已安装，现有工具通常会被替换。

用法

uv tool install [OPTIONS] <PACKAGE>

参数

PACKAGE: 要从中安装命令的包

选项

--allow-insecure-host, --trusted-host allow-insecure-host

允许连接到不安全的主机。

可以多次提供。

期望接收主机名（例如 localhost）、主机-端口对（例如 localhost:8080）或 URL（例如 https://localhost）。

警告：此列表中的主机将不会根据系统的证书存储进行验证。仅在具有已验证来源的安全网络中使用 --allow-insecure-host，因为它会绕过 SSL 验证，可能使您面临中间人攻击（MITM）的风险。

也可以通过 UV_INSECURE_HOST 环境变量设置。

--build-constraints, --build-constraint, -b build-constraints

在构建源码分发包时，使用给定的 requirements 文件约束构建依赖项。

约束文件是类似 requirements.txt 的文件，仅控制所安装依赖项的版本。但是，在约束文件中包含某个包不会触发该包的安装。

也可以通过 UV_BUILD_CONSTRAINT 环境变量设置。

--cache-dir cache-dir

缓存目录的路径。

在 macOS 和 Linux 上默认为 $XDG_CACHE_HOME/uv 或 $HOME/.cache/uv，在 Windows 上为 %LOCALAPPDATA%\uv\cache。

要查看缓存目录的位置，请运行 uv cache dir。

也可以通过 UV_CACHE_DIR 环境变量设置。

--color color-choice

控制输出中颜色的使用。

默认情况下，uv 会在写入终端时自动检测是否支持颜色。

可能的值：

auto：仅当输出到支持颜色的终端或 TTY 时启用彩色输出
always：无论检测到的环境如何，始终启用彩色输出
never：禁用彩色输出

--compile-bytecode, --compile

安装后将 Python 文件编译为字节码。

默认情况下，uv 不会将 Python（.py）文件编译为字节码（__pycache__/*.pyc）；相反，编译会在首次导入模块时延迟执行。对于启动时间至关重要的用例（如 CLI 应用程序和 Docker 容器），可以启用此选项，以较长的安装时间换取更快的启动时间。

启用后，uv 将处理整个 site-packages 目录（包括当前操作未修改的包）以保持一致性。与 pip 类似，它也会忽略错误。

也可以通过 UV_COMPILE_BYTECODE 环境变量设置。

--config-file config-file

用于配置的 uv.toml 文件路径。

虽然 uv 配置可以包含在 pyproject.toml 文件中，但在此上下文中不允许使用。

也可以通过 UV_CONFIG_FILE 环境变量设置。

--config-setting, --config-settings, -C config-setting

传递给 PEP 517 构建后端的设置，以 KEY=VALUE 对的形式指定

--config-settings-package, --config-settings-package config-settings-package

为特定包传递给 PEP 517 构建后端的设置，以 PACKAGE:KEY=VALUE 对的形式指定

--constraints, --constraint, -c constraints

使用给定的 requirements 文件约束版本。

约束文件是类似 requirements.txt 的文件，仅控制所安装依赖项的版本。但是，在约束文件中包含某个包不会触发该包的安装。

这等同于 pip 的 --constraint 选项。

也可以通过 UV_CONSTRAINT 环境变量设置。

--default-index default-index

默认包索引的 URL（默认为 https://pypi.org/simple）。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

此标志指定的索引优先级低于通过 --index 标志指定的所有其他索引。

也可以通过 UV_DEFAULT_INDEX 环境变量设置。

--directory directory

在运行命令之前切换到给定目录。

相对路径以给定目录为基准进行解析。

参见 --project 以仅更改项目根目录。

也可以通过 UV_WORKING_DIR 环境变量设置。

--editable, -e

以可编辑模式安装目标包，这样对包源码目录的更改无需重新安装即可反映

--exclude-newer exclude-newer

将候选包限制为在给定日期之前上传的版本。

日期与每个分发包构件的上传时间（即每个文件上传到包索引的时间）进行比较，而非包版本的发布日期。

接受 RFC 3339 时间戳（例如 2006-12-02T02:07:43Z）、基于系统配置时区解析的相同格式的本地日期（例如 2006-12-02）、"友好"持续时间（例如 24 hours、1 week、30 days）或 ISO 8601 持续时间（例如 PT24H、P7D、P30D）。

持续时间不考虑本地时区的语义，始终解析为固定的秒数，假设一天为 24 小时（例如，忽略夏令时转换）。不允许使用月份和年份等日历单位。

也可以通过 UV_EXCLUDE_NEWER 环境变量设置。

--exclude-newer-package exclude-newer-package

将特定包的候选包限制为在给定日期之前上传的版本。

接受 PACKAGE=DATE 格式的包-日期对，其中 DATE 是 RFC 3339 时间戳（例如 2006-12-02T02:07:43Z）、基于系统配置时区解析的相同格式的本地日期（例如 2006-12-02）、"友好"持续时间（例如 24 hours、1 week、30 days）或 ISO 8601 持续时间（例如 PT24H、P7D、P30D）。

持续时间不考虑本地时区的语义，始终解析为固定的秒数，假设一天为 24 小时（例如，忽略夏令时转换）。不允许使用月份和年份等日历单位。

可以为不同的包多次提供。

--excludes, --exclude excludes

使用给定的 requirements 文件从解析中排除包。

排除文件是类似 requirements.txt 的文件，指定要从解析中排除的包。当包被排除时，它将完全从依赖项列表中省略，并且在解析阶段其自身的依赖项也将被忽略。排除是无条件的，需求说明符和标记将被忽略；提供的文件中列出的任何包都将从所有已解析的环境中省略。

也可以通过 UV_EXCLUDE 环境变量设置。

--extra-index-url extra-index-url

（已弃用：请改用 --index）除 --index-url 之外，要使用的额外包索引 URL。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

通过此标志提供的所有索引优先级高于 --index-url（默认为 PyPI）指定的索引。当提供多个 --extra-index-url 标志时，较早的值优先。

也可以通过 UV_EXTRA_INDEX_URL 环境变量设置。

--find-links, -f find-links

除注册表索引中找到的分发包外，还要搜索候选分发包的位置。

如果是路径，目标必须是一个目录，其中包含顶层 wheel 文件（.whl）或源码分发包（例如 .tar.gz 或 .zip）。

如果是 URL，页面必须包含指向符合上述格式的包文件的扁平链接列表。

也可以通过 UV_FIND_LINKS 环境变量设置。

--force

强制安装工具。

将重新创建工具的任何现有环境，并替换可执行文件目录中任何同名的现有入口点。

--fork-strategy fork-strategy

在跨 Python 版本和平台为给定包选择多个版本时使用的策略。

默认情况下，uv 会优化为每个支持的 Python 版本（requires-python）选择每个包的最新版本，同时最小化跨平台选择的版本数量。

在 fewest 策略下，uv 将最小化每个包选择的版本数量，优先选择与更广泛支持的 Python 版本或平台兼容的旧版本。

也可以通过 UV_FORK_STRATEGY 环境变量设置。

可能的值：

fewest：优化为每个包选择最少数量的版本。如果旧版本与更广泛支持的 Python 版本或平台兼容，则可能优先选择旧版本
requires-python：为每个支持的 Python 版本优化选择每个包的最新支持版本

--help, -h

显示此命令的简要帮助

--index index

解析依赖项时使用的 URL，除默认索引之外。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

通过此标志提供的所有索引优先级高于 --default-index（默认为 PyPI）指定的索引。当提供多个 --index 标志时，较早的值优先。

不支持索引名称作为值。相对路径必须通过 ./ 或 ../（Unix）或 .\\、..\\、./ 或 ../（Windows）与索引名称区分开来。

也可以通过 UV_INDEX 环境变量设置。

--index-strategy index-strategy

针对多个索引 URL 进行解析时使用的策略。

默认情况下，uv 会在第一个找到给定包的索引处停止，并将解析限制为该第一个索引上存在的版本（first-index）。这可以防止"依赖混淆"攻击，即攻击者可以在备用索引上以相同名称上传恶意包。

也可以通过 UV_INDEX_STRATEGY 环境变量设置。

可能的值：

first-index：仅使用第一个返回给定包名匹配结果的索引
unsafe-first-match：在所有索引中搜索每个包名，先穷尽第一个索引的版本，然后再转到下一个
unsafe-best-match：在所有索引中搜索每个包名，优先选择找到的"最佳"版本。如果一个包版本存在于多个索引中，则只查看第一个索引的条目

--index-url, -i index-url

（已弃用：请改用 --default-index）Python 包索引的 URL（默认为 https://pypi.org/simple）。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

此标志指定的索引优先级低于通过 --extra-index-url 标志指定的所有其他索引。

也可以通过 UV_INDEX_URL 环境变量设置。

--keyring-provider keyring-provider

尝试使用 keyring 进行索引 URL 的身份验证。

目前仅支持 --keyring-provider subprocess，它配置 uv 使用 keyring CLI 来处理身份验证。

默认为 disabled。

也可以通过 UV_KEYRING_PROVIDER 环境变量设置。

可能的值：

disabled：不使用 keyring 进行凭据查找
subprocess：使用 keyring 命令进行凭据查找

--link-mode link-mode

从全局缓存安装包时使用的方法。

在 macOS 和 Linux 上默认为 clone（也称为写时复制），在 Windows 上默认为 hardlink。

警告：不鼓励使用 symlink 链接模式，因为它会在缓存和目标环境之间创建紧密耦合。例如，清除缓存（uv cache clean）将通过删除底层源文件来破坏所有已安装的包。请谨慎使用符号链接。

也可以通过 UV_LINK_MODE 环境变量设置。

可能的值：

clone：将包从源克隆（即写时复制）到目标
copy：将包从源复制到目标
hardlink：将包从源硬链接到目标
symlink：将包从源符号链接到目标

--managed-python

要求使用 uv 管理的 Python 版本 [env: UV_MANAGED_PYTHON=]

默认情况下，uv 优先使用它管理的 Python 版本。但是，如果未安装 uv 管理的 Python，它将使用系统 Python 版本。此选项禁用系统 Python 版本的使用。

--no-binary

不安装预编译的 wheel。

给定的包将从源码构建和安装。解析器仍将使用预编译的 wheel 来提取包元数据（如果可用）。

也可以通过 UV_NO_BINARY 环境变量设置。

--no-binary-package no-binary-package

不为特定包安装预编译的 wheel [env: UV_NO_BINARY_PACKAGE=]

--no-build

不构建源码分发包。

启用后，解析将不会运行任意 Python 代码。已构建的源码分发包的缓存 wheel 将被重用，但需要构建分发包的操作将退出并报错。

也可以通过 UV_NO_BUILD 环境变量设置。

--no-build-isolation

构建源码分发包时禁用隔离。

假定 PEP 518 指定的构建依赖项已安装。

也可以通过 UV_NO_BUILD_ISOLATION 环境变量设置。

--no-build-isolation-package no-build-isolation-package

为特定包构建源码分发包时禁用隔离。

假定该包的 PEP 518 构建依赖项已安装。

--no-build-package no-build-package

不为特定包构建源码分发包 [env: UV_NO_BUILD_PACKAGE=]

--no-cache, --no-cache-dir, -n

避免读取或写入缓存，在操作期间改用临时目录

也可以通过 UV_NO_CACHE 环境变量设置。

--no-config

避免发现配置文件（pyproject.toml、uv.toml）。

正常情况下，配置文件会在当前目录、父目录或用户配置目录中被发现。

也可以通过 UV_NO_CONFIG 环境变量设置。

--no-index

忽略注册表索引（例如 PyPI），转而依赖直接 URL 依赖项和通过 --find-links 提供的依赖项

--no-managed-python

禁用 uv 管理的 Python 版本 [env: UV_NO_MANAGED_PYTHON=]

相反，uv 将在系统上搜索合适的 Python 版本。

--no-progress

隐藏所有进度输出 [env: UV_NO_PROGRESS=]

例如，旋转指示器或进度条。

--no-python-downloads

禁用 Python 的自动下载。

--no-sources

解析依赖项时忽略 tool.uv.sources 表。用于根据符合标准、可发布的包元数据进行锁定，而不是使用任何工作区、Git、URL 或本地路径源

也可以通过 UV_NO_SOURCES 环境变量设置。

--no-sources-package no-sources-package

不为指定包使用 tool.uv.sources 表中的源 [env: UV_NO_SOURCES_PACKAGE=]

--offline

禁用网络访问 [env: UV_OFFLINE=]

禁用后，uv 将仅使用本地缓存数据和本地可用文件。

--overrides, --override overrides

使用给定的 requirements 文件覆盖版本。

覆盖文件是类似 requirements.txt 的文件，强制安装特定版本的需求，无论任何组成包声明了什么需求，也无论这是否会被视为无效的解析。

约束是附加性的，即它们与组成包的需求相结合；而覆盖是绝对性的，即它们完全替换组成包的需求。

也可以通过 UV_OVERRIDE 环境变量设置。

--prerelease prerelease

考虑预发布版本时使用的策略。

默认情况下，uv 将接受仅发布预发布版本的包的预发布版本，以及声明的版本说明符中包含显式预发布标记的第一方依赖项（if-necessary-or-explicit）。

也可以通过 UV_PRERELEASE 环境变量设置。

可能的值：

disallow：禁止所有预发布版本
allow：允许所有预发布版本
if-necessary：如果包的所有版本都是预发布版本，则允许预发布版本
explicit：允许版本要求中包含显式预发布标记的第一方包的预发布版本
if-necessary-or-explicit：如果包的所有版本都是预发布版本，或者包在其版本要求中有显式预发布标记，则允许预发布版本

--project project

在给定目录中发现项目。

所有 pyproject.toml、uv.toml 和 .python-version 文件将通过从项目根目录向上遍历目录树来发现，项目的虚拟环境（.venv）也是如此。

其他命令行参数（如相对路径）将相对于当前工作目录进行解析。

参见 --directory 以完全更改工作目录。

此设置在 uv pip 接口中使用时无效。

也可以通过 UV_PROJECT 环境变量设置。

--python, -p python

用于构建工具环境的 Python 解释器。

有关 Python 发现和支持的请求格式的详细信息，请参见 uv python。

也可以通过 UV_PYTHON 环境变量设置。

--python-platform python-platform

应为其安装依赖项的平台。

表示为"目标三元组"，一个描述目标平台的字符串，包含其 CPU、供应商和操作系统名称，如 x86_64-unknown-linux-gnu 或 aarch64-apple-darwin。

当目标为 macOS（Darwin）时，默认最低版本为 13.0。使用 MACOSX_DEPLOYMENT_TARGET 指定不同的最低版本，例如 14.0。

当目标为 iOS 时，默认最低版本为 13.0。使用 IPHONEOS_DEPLOYMENT_TARGET 指定不同的最低版本，例如 14.0。

当目标为 Android 时，默认最低 Android API 级别为 24。使用 ANDROID_API_LEVEL 指定不同的最低版本，例如 26。

警告：指定后，uv 将选择与目标平台兼容的 wheel；因此，已安装的分发包可能与当前平台不兼容。相反，从源码构建的任何分发包可能与目标平台不兼容，因为它们将针对当前平台构建。--python-platform 选项适用于高级用例。

可能的值：

windows：x86_64-pc-windows-msvc 的别名，Windows 的默认目标
linux：x86_64-unknown-linux-gnu 的别名，Linux 的默认目标
macos：aarch64-apple-darwin 的别名，macOS 的默认目标
x86_64-pc-windows-msvc：64 位 x86 Windows 目标
aarch64-pc-windows-msvc：ARM64 Windows 目标
i686-pc-windows-msvc：32 位 x86 Windows 目标
x86_64-unknown-linux-gnu：x86 Linux 目标。等同于 x86_64-manylinux_2_28
aarch64-apple-darwin：基于 ARM 的 macOS 目标，如 Apple Silicon 设备所示
x86_64-apple-darwin：x86 macOS 目标
aarch64-unknown-linux-gnu：ARM64 Linux 目标。等同于 aarch64-manylinux_2_28
aarch64-unknown-linux-musl：ARM64 Linux 目标
x86_64-unknown-linux-musl：x86_64 Linux 目标
riscv64-unknown-linux：RISCV64 Linux 目标
x86_64-manylinux2014：manylinux2014 平台的 x86_64 目标。等同于 x86_64-manylinux_2_17
x86_64-manylinux_2_17：manylinux_2_17 平台的 x86_64 目标
x86_64-manylinux_2_28：manylinux_2_28 平台的 x86_64 目标
x86_64-manylinux_2_31：manylinux_2_31 平台的 x86_64 目标
x86_64-manylinux_2_32：manylinux_2_32 平台的 x86_64 目标
x86_64-manylinux_2_33：manylinux_2_33 平台的 x86_64 目标
x86_64-manylinux_2_34：manylinux_2_34 平台的 x86_64 目标
x86_64-manylinux_2_35：manylinux_2_35 平台的 x86_64 目标
x86_64-manylinux_2_36：manylinux_2_36 平台的 x86_64 目标
x86_64-manylinux_2_37：manylinux_2_37 平台的 x86_64 目标
x86_64-manylinux_2_38：manylinux_2_38 平台的 x86_64 目标
x86_64-manylinux_2_39：manylinux_2_39 平台的 x86_64 目标
x86_64-manylinux_2_40：manylinux_2_40 平台的 x86_64 目标
aarch64-manylinux2014：manylinux2014 平台的 ARM64 目标。等同于 aarch64-manylinux_2_17
aarch64-manylinux_2_17：manylinux_2_17 平台的 ARM64 目标
aarch64-manylinux_2_28：manylinux_2_28 平台的 ARM64 目标
aarch64-manylinux_2_31：manylinux_2_31 平台的 ARM64 目标
aarch64-manylinux_2_32：manylinux_2_32 平台的 ARM64 目标
aarch64-manylinux_2_33：manylinux_2_33 平台的 ARM64 目标
aarch64-manylinux_2_34：manylinux_2_34 平台的 ARM64 目标
aarch64-manylinux_2_35：manylinux_2_35 平台的 ARM64 目标
aarch64-manylinux_2_36：manylinux_2_36 平台的 ARM64 目标
aarch64-manylinux_2_37：manylinux_2_37 平台的 ARM64 目标
aarch64-manylinux_2_38：manylinux_2_38 平台的 ARM64 目标
aarch64-manylinux_2_39：manylinux_2_39 平台的 ARM64 目标
aarch64-manylinux_2_40：manylinux_2_40 平台的 ARM64 目标
aarch64-linux-android：ARM64 Android 目标
x86_64-linux-android：x86_64 Android 目标
wasm32-pyodide2024：使用 Pyodide 2024 平台的 wasm32 目标。适用于 Python 3.12。参见 https://pyodide.org/en/stable/development/abi/312.html
wasm32-pyodide2025：使用 Pyodide 2025 平台的 wasm32 目标。适用于 Python 3.13。参见 https://pyodide.org/en/stable/development/abi/313.html
arm64-apple-ios：iOS 设备的 ARM64 目标
arm64-apple-ios-simulator：iOS 模拟器的 ARM64 目标
x86_64-apple-ios-simulator：iOS 模拟器的 x86_64 目标

--quiet, -q

使用静默输出。

重复此选项，例如 -qq，将启用静默模式，uv 将不会向 stdout 写入任何输出。

--refresh

刷新所有缓存数据

--refresh-package refresh-package

刷新特定包的缓存数据

--reinstall, --force-reinstall

重新安装所有包，无论它们是否已安装。隐含 --refresh

--reinstall-package reinstall-package

重新安装特定包，无论它是否已安装。隐含 --refresh-package

--resolution resolution

在给定包的不同兼容版本之间进行选择时使用的策略。

默认情况下，uv 将使用每个包的最新兼容版本（highest）。

也可以通过 UV_RESOLUTION 环境变量设置。

可能的值：

highest：解析每个包的最高兼容版本
lowest：解析每个包的最低兼容版本
lowest-direct：解析任何直接依赖项的最低兼容版本，以及任何传递依赖项的最高兼容版本

--system-certs

是否从平台的原生证书存储加载 TLS 证书 [env: UV_SYSTEM_CERTS=]

默认情况下，uv 使用捆绑的 Mozilla 根证书，这提高了可移植性和性能（尤其是在 macOS 上）。

但是，在某些情况下，您可能希望使用平台的原生证书存储，特别是当您依赖系统证书存储中包含的企业信任根（例如，用于强制代理）时。

--torch-backend torch-backend

获取 PyTorch 生态系统中的包时使用的后端（例如 cpu、cu126 或 auto）

设置后，uv 将忽略 PyTorch 生态系统中包的已配置索引 URL，转而使用定义的后端。

例如，当设置为 cpu 时，uv 将使用仅 CPU 的 PyTorch 索引；当设置为 cu126 时，uv 将使用 CUDA 12.6 的 PyTorch 索引。

auto 模式将尝试根据当前安装的 CUDA 驱动程序检测适当的 PyTorch 索引。

此选项处于预览阶段，可能在任何未来版本中发生更改。

也可以通过 UV_TORCH_BACKEND 环境变量设置。

可能的值：

auto：根据操作系统和 CUDA 驱动程序版本选择适当的 PyTorch 索引
cpu：使用仅 CPU 的 PyTorch 索引
cu130：使用 CUDA 13.0 的 PyTorch 索引
cu129：使用 CUDA 12.9 的 PyTorch 索引
cu128：使用 CUDA 12.8 的 PyTorch 索引
cu126：使用 CUDA 12.6 的 PyTorch 索引
cu125：使用 CUDA 12.5 的 PyTorch 索引
cu124：使用 CUDA 12.4 的 PyTorch 索引
cu123：使用 CUDA 12.3 的 PyTorch 索引
cu122：使用 CUDA 12.2 的 PyTorch 索引
cu121：使用 CUDA 12.1 的 PyTorch 索引
cu120：使用 CUDA 12.0 的 PyTorch 索引
cu118：使用 CUDA 11.8 的 PyTorch 索引
cu117：使用 CUDA 11.7 的 PyTorch 索引
cu116：使用 CUDA 11.6 的 PyTorch 索引
cu115：使用 CUDA 11.5 的 PyTorch 索引
cu114：使用 CUDA 11.4 的 PyTorch 索引
cu113：使用 CUDA 11.3 的 PyTorch 索引
cu112：使用 CUDA 11.2 的 PyTorch 索引
cu111：使用 CUDA 11.1 的 PyTorch 索引
cu110：使用 CUDA 11.0 的 PyTorch 索引
cu102：使用 CUDA 10.2 的 PyTorch 索引
cu101：使用 CUDA 10.1 的 PyTorch 索引
cu100：使用 CUDA 10.0 的 PyTorch 索引
cu92：使用 CUDA 9.2 的 PyTorch 索引
cu91：使用 CUDA 9.1 的 PyTorch 索引
cu90：使用 CUDA 9.0 的 PyTorch 索引
cu80：使用 CUDA 8.0 的 PyTorch 索引
rocm7.2：使用 ROCm 7.2 的 PyTorch 索引
rocm7.1：使用 ROCm 7.1 的 PyTorch 索引
rocm7.0：使用 ROCm 7.0 的 PyTorch 索引
rocm6.4：使用 ROCm 6.4 的 PyTorch 索引
rocm6.3：使用 ROCm 6.3 的 PyTorch 索引
rocm6.2.4：使用 ROCm 6.2.4 的 PyTorch 索引
rocm6.2：使用 ROCm 6.2 的 PyTorch 索引
rocm6.1：使用 ROCm 6.1 的 PyTorch 索引
rocm6.0：使用 ROCm 6.0 的 PyTorch 索引
rocm5.7：使用 ROCm 5.7 的 PyTorch 索引
rocm5.6：使用 ROCm 5.6 的 PyTorch 索引
rocm5.5：使用 ROCm 5.5 的 PyTorch 索引
rocm5.4.2：使用 ROCm 5.4.2 的 PyTorch 索引
rocm5.4：使用 ROCm 5.4 的 PyTorch 索引
rocm5.3：使用 ROCm 5.3 的 PyTorch 索引
rocm5.2：使用 ROCm 5.2 的 PyTorch 索引
rocm5.1.1：使用 ROCm 5.1.1 的 PyTorch 索引
rocm4.2：使用 ROCm 4.2 的 PyTorch 索引
rocm4.1：使用 ROCm 4.1 的 PyTorch 索引
rocm4.0.1：使用 ROCm 4.0.1 的 PyTorch 索引
xpu：使用 Intel XPU 的 PyTorch 索引

--upgrade, -U

允许包升级，忽略任何现有输出文件中的固定版本。隐含 --refresh

--upgrade-group upgrade-group

允许依赖组中所有包的升级，忽略任何现有输出文件中的固定版本

--upgrade-package, -P upgrade-package

允许特定包的升级，忽略任何现有输出文件中的固定版本。隐含 --refresh-package

--verbose, -v

使用详细输出。

您可以使用 RUST_LOG 环境变量配置细粒度日志记录。（https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#directives）

--with, -w with

包含以下额外的依赖项

--with-editable with-editable

以可编辑模式包含给定的包

--with-executables-from with-executables-from

从以下包安装可执行文件

--with-requirements with-requirements

使用给定文件中列出的包运行。

支持以下格式：requirements.txt、带有内联元数据的 .py 文件和 pylock.toml。

uv tool upgrade

升级已安装的工具。

如果工具在安装时带有版本约束，升级时将遵守这些约束——要升级到超出最初提供约束的版本，请再次使用 uv tool install。

如果工具在安装时带有特定设置，升级时将遵守这些设置。例如，如果在安装期间提供了 --prereleases allow，升级时将继续遵守该设置。

用法

uv tool upgrade [OPTIONS] <NAME>...

参数

NAME: 要升级的工具名称，可附带可选的版本说明符

选项

--all

升级所有工具

--allow-insecure-host, --trusted-host allow-insecure-host

允许连接到不安全的主机。

可以多次提供。

期望接收主机名（例如 localhost）、主机-端口对（例如 localhost:8080）或 URL（例如 https://localhost）。

警告：此列表中的主机将不会根据系统的证书存储进行验证。仅在具有已验证来源的安全网络中使用 --allow-insecure-host，因为它会绕过 SSL 验证，可能使您面临中间人攻击（MITM）的风险。

也可以通过 UV_INSECURE_HOST 环境变量设置。

--cache-dir cache-dir

缓存目录的路径。

在 macOS 和 Linux 上默认为 $XDG_CACHE_HOME/uv 或 $HOME/.cache/uv，在 Windows 上为 %LOCALAPPDATA%\uv\cache。

要查看缓存目录的位置，请运行 uv cache dir。

也可以通过 UV_CACHE_DIR 环境变量设置。

--color color-choice

控制输出中颜色的使用。

默认情况下，uv 会在写入终端时自动检测是否支持颜色。

可能的值：

auto：仅当输出到支持颜色的终端或 TTY 时启用彩色输出
always：无论检测到的环境如何，始终启用彩色输出
never：禁用彩色输出

--compile-bytecode, --compile

安装后将 Python 文件编译为字节码。

默认情况下，uv 不会将 Python（.py）文件编译为字节码（__pycache__/*.pyc）；相反，编译会在首次导入模块时延迟执行。对于启动时间至关重要的用例（如 CLI 应用程序和 Docker 容器），可以启用此选项，以较长的安装时间换取更快的启动时间。

启用后，uv 将处理整个 site-packages 目录（包括当前操作未修改的包）以保持一致性。与 pip 类似，它也会忽略错误。

也可以通过 UV_COMPILE_BYTECODE 环境变量设置。

--config-file config-file

用于配置的 uv.toml 文件路径。

虽然 uv 配置可以包含在 pyproject.toml 文件中，但在此上下文中不允许使用。

也可以通过 UV_CONFIG_FILE 环境变量设置。

--config-setting, --config-settings, -C config-setting

传递给 PEP 517 构建后端的设置，以 KEY=VALUE 对的形式指定

--config-setting-package, --config-settings-package config-setting-package

为特定包传递给 PEP 517 构建后端的设置，以 PACKAGE:KEY=VALUE 对的形式指定

--default-index default-index

默认包索引的 URL（默认为 https://pypi.org/simple）。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

此标志指定的索引优先级低于通过 --index 标志指定的所有其他索引。

也可以通过 UV_DEFAULT_INDEX 环境变量设置。

--directory directory

在运行命令之前切换到给定目录。

相对路径以给定目录为基准进行解析。

参见 --project 以仅更改项目根目录。

也可以通过 UV_WORKING_DIR 环境变量设置。

--exclude-newer exclude-newer

将候选包限制为在给定日期之前上传的版本。

日期与每个分发包构件的上传时间（即每个文件上传到包索引的时间）进行比较，而非包版本的发布日期。

接受 RFC 3339 时间戳（例如 2006-12-02T02:07:43Z）、基于系统配置时区解析的相同格式的本地日期（例如 2006-12-02）、"友好"持续时间（例如 24 hours、1 week、30 days）或 ISO 8601 持续时间（例如 PT24H、P7D、P30D）。

持续时间不考虑本地时区的语义，始终解析为固定的秒数，假设一天为 24 小时（例如，忽略夏令时转换）。不允许使用月份和年份等日历单位。

也可以通过 UV_EXCLUDE_NEWER 环境变量设置。

--exclude-newer-package exclude-newer-package

将特定包的候选包限制为在给定日期之前上传的版本。

接受 PACKAGE=DATE 格式的包-日期对，其中 DATE 是 RFC 3339 时间戳（例如 2006-12-02T02:07:43Z）、基于系统配置时区解析的相同格式的本地日期（例如 2006-12-02）、"友好"持续时间（例如 24 hours、1 week、30 days）或 ISO 8601 持续时间（例如 PT24H、P7D、P30D）。

持续时间不考虑本地时区的语义，始终解析为固定的秒数，假设一天为 24 小时（例如，忽略夏令时转换）。不允许使用月份和年份等日历单位。

可以为不同的包多次提供。

--extra-index-url extra-index-url

（已弃用：请改用 --index）除 --index-url 之外，要使用的额外包索引 URL。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

通过此标志提供的所有索引优先级高于 --index-url（默认为 PyPI）指定的索引。当提供多个 --extra-index-url 标志时，较早的值优先。

也可以通过 UV_EXTRA_INDEX_URL 环境变量设置。

--find-links, -f find-links

除注册表索引中找到的分发包外，还要搜索候选分发包的位置。

如果是路径，目标必须是一个目录，其中包含顶层 wheel 文件（.whl）或源码分发包（例如 .tar.gz 或 .zip）。

如果是 URL，页面必须包含指向符合上述格式的包文件的扁平链接列表。

也可以通过 UV_FIND_LINKS 环境变量设置。

--fork-strategy fork-strategy

在跨 Python 版本和平台为给定包选择多个版本时使用的策略。

默认情况下，uv 会优化为每个支持的 Python 版本（requires-python）选择每个包的最新版本，同时最小化跨平台选择的版本数量。

在 fewest 策略下，uv 将最小化每个包选择的版本数量，优先选择与更广泛支持的 Python 版本或平台兼容的旧版本。

也可以通过 UV_FORK_STRATEGY 环境变量设置。

可能的值：

fewest：优化为每个包选择最少数量的版本。如果旧版本与更广泛支持的 Python 版本或平台兼容，则可能优先选择旧版本
requires-python：为每个支持的 Python 版本优化选择每个包的最新支持版本

--help, -h

显示此命令的简要帮助

--index index

解析依赖项时使用的 URL，除默认索引之外。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

通过此标志提供的所有索引优先级高于 --default-index（默认为 PyPI）指定的索引。当提供多个 --index 标志时，较早的值优先。

不支持索引名称作为值。相对路径必须通过 ./ 或 ../（Unix）或 .\\、..\\、./ 或 ../（Windows）与索引名称区分开来。

也可以通过 UV_INDEX 环境变量设置。

--index-strategy index-strategy

针对多个索引 URL 进行解析时使用的策略。

默认情况下，uv 会在第一个找到给定包的索引处停止，并将解析限制为该第一个索引上存在的版本（first-index）。这可以防止"依赖混淆"攻击，即攻击者可以在备用索引上以相同名称上传恶意包。

也可以通过 UV_INDEX_STRATEGY 环境变量设置。

可能的值：

first-index：仅使用第一个返回给定包名匹配结果的索引
unsafe-first-match：在所有索引中搜索每个包名，先穷尽第一个索引的版本，然后再转到下一个
unsafe-best-match：在所有索引中搜索每个包名，优先选择找到的"最佳"版本。如果一个包版本存在于多个索引中，则只查看第一个索引的条目

--index-url, -i index-url

（已弃用：请改用 --default-index）Python 包索引的 URL（默认为 https://pypi.org/simple）。

接受符合 PEP 503（简单仓库 API）的仓库，或以相同格式组织的本地目录。

此标志指定的索引优先级低于通过 --extra-index-url 标志指定的所有其他索引。

也可以通过 UV_INDEX_URL 环境变量设置。

--keyring-provider keyring-provider

尝试使用 keyring 进行索引 URL 的身份验证。

目前仅支持 --keyring-provider subprocess，它配置 uv 使用 keyring CLI 来处理身份验证。

默认为 disabled。

也可以通过 UV_KEYRING_PROVIDER 环境变量设置。

可能的值：

disabled：不使用 keyring 进行凭据查找
subprocess：使用 keyring 命令进行凭据查找

--link-mode link-mode

从全局缓存安装包时使用的方法。

在 macOS 和 Linux 上默认为 clone（也称为写时复制），在 Windows 上默认为 hardlink。

警告：不鼓励使用 symlink 链接模式，因为它会在缓存和目标环境之间创建紧密耦合。例如，清除缓存（uv cache clean）将通过删除底层源文件来破坏所有已安装的包。请谨慎使用符号链接。

也可以通过 UV_LINK_MODE 环境变量设置。

可能的值：

clone：将包从源克隆（即写时复制）到目标
copy：将包从源复制到目标
hardlink：将包从源硬链接到目标
symlink：将包从源符号链接到目标

--managed-python

要求使用 uv 管理的 Python 版本 [env: UV_MANAGED_PYTHON=]

默认情况下，uv 优先使用它管理的 Python 版本。但是，如果未安装 uv 管理的 Python，它将使用系统 Python 版本。此选项禁用系统 Python 版本的使用。

--no-binary

不安装预编译的 wheel。

给定的包将从源码构建和安装。解析器仍将使用预编译的 wheel 来提取包元数据（如果可用）。

也可以通过 UV_NO_BINARY 环境变量设置。

--no-binary-package no-binary-package

不为特定包安装预编译的 wheel [env: UV_NO_BINARY_PACKAGE=]

--no-build

不构建源码分发包。

启用后，解析将不会运行任意 Python 代码。已构建的源码分发包的缓存 wheel 将被重用，但需要构建分发包的操作将退出并报错。

也可以通过 UV_NO_BUILD 环境变量设置。

--no-build-isolation

构建源码分发包时禁用隔离。

假定 PEP 518 指定的构建依赖项已安装。

也可以通过 UV_NO_BUILD_ISOLATION 环境变量设置。

--no-build-isolation-package no-build-isolation-package

为特定包构建源码分发包时禁用隔离。

假定该包的 PEP 518 构建依赖项已安装。

--no-build-package no-build-package

不为特定包构建源码分发包 [env: UV_NO_BUILD_PACKAGE=]

--no-cache, --no-cache-dir, -n

避免读取或写入缓存，在操作期间改用临时目录

也可以通过 UV_NO_CACHE 环境变量设置。

--no-config

避免发现配置文件（pyproject.toml、uv.toml）。

正常情况下，配置文件会在当前目录、父目录或用户配置目录中被发现。

也可以通过 UV_NO_CONFIG 环境变量设置。

--no-index

忽略注册表索引（例如 PyPI），转而依赖直接 URL 依赖项和通过 --find-links 提供的依赖项

--no-managed-python

禁用 uv 管理的 Python 版本 [env: UV_NO_MANAGED_PYTHON=]

相反，uv 将在系统上搜索合适的 Python 版本。

--no-progress

隐藏所有进度输出 [env: UV_NO_PROGRESS=]

例如，旋转指示器或进度条。

--no-python-downloads

禁用 Python 的自动下载。

--no-sources

解析依赖项时忽略 tool.uv.sources 表。用于根据符合标准、可发布的包元数据进行锁定，而不是使用任何工作区、Git、URL 或本地路径源

也可以通过 UV_NO_SOURCES 环境变量设置。

--no-sources-package no-sources-package

不为指定包使用 tool.uv.sources 表中的源 [env: UV_NO_SOURCES_PACKAGE=]

--offline

禁用网络访问 [env: UV_OFFLINE=]

禁用后，uv 将仅使用本地缓存数据和本地可用文件。

--prerelease prerelease

考虑预发布版本时使用的策略。

默认情况下，uv 将接受仅发布预发布版本的包的预发布版本，以及声明的版本说明符中包含显式预发布标记的第一方依赖项（if-necessary-or-explicit）。

也可以通过 UV_PRERELEASE 环境变量设置。

可能的值：

disallow：禁止所有预发布版本
allow：允许所有预发布版本
if-necessary：如果包的所有版本都是预发布版本，则允许预发布版本
explicit：允许版本要求中包含显式预发布标记的第一方包的预发布版本
if-necessary-or-explicit：如果包的所有版本都是预发布版本，或者包在其版本要求中有显式预发布标记，则允许预发布版本

--python, -p python

用于构建工具环境的 Python 解释器。

有关 Python 发现和支持的请求格式的详细信息，请参见 uv python。

也可以通过 UV_PYTHON 环境变量设置。

--python-platform python-platform

应为其安装依赖项的平台。

表示为"目标三元组"，一个描述目标平台的字符串，包含其 CPU、供应商和操作系统名称，如 x86_64-unknown-linux-gnu 或 aarch64-apple-darwin。

当目标为 macOS（Darwin）时，默认最低版本为 13.0。使用 MACOSX_DEPLOYMENT_TARGET 指定不同的最低版本，例如 14.0。

当目标为 iOS 时，默认最低版本为 13.0。使用 IPHONEOS_DEPLOYMENT_TARGET 指定不同的最低版本，例如 14.0。

当目标为 Android 时，默认最低 Android API 级别为 24。使用 ANDROID_API_LEVEL 指定不同的最低版本，例如 26。

警告：指定后，uv 将选择与目标平台兼容的 wheel；因此，已安装的分发包可能与当前平台不兼容。相反，从源码构建的任何分发包可能与目标平台不兼容，因为它们将针对当前平台构建。--python-platform 选项适用于高级用例。

可能的值：

windows：x86_64-pc-windows-msvc 的别名，Windows 的默认目标
linux：x86_64-unknown-linux-gnu 的别名，Linux 的默认目标
macos：aarch64-apple-darwin 的别名，macOS 的默认目标
x86_64-pc-windows-msvc：64 位 x86 Windows 目标
aarch64-pc-windows-msvc：ARM64 Windows 目标
i686-pc-windows-msvc：32 位 x86 Windows 目标
x86_64-unknown-linux-gnu：x86 Linux 目标。等同于 x86_64-manylinux_2_28
aarch64-apple-darwin：基于 ARM 的 macOS 目标，如 Apple Silicon 设备所示
x86_64-apple-darwin：x86 macOS 目标
aarch64-unknown-linux-gnu：ARM64 Linux 目标。等同于 aarch64-manylinux_2_28
aarch64-unknown-linux-musl：ARM64 Linux 目标
x86_64-unknown-linux-musl：x86_64 Linux 目标
riscv64-unknown-linux：RISCV64 Linux 目标
x86_64-manylinux2014：manylinux2014 平台的 x86_64 目标。等同于 x86_64-manylinux_2_17
x86_64-manylinux_2_17：manylinux_2_17 平台的 x86_64 目标
x86_64-manylinux_2_28：manylinux_2_28 平台的 x86_64 目标
x86_64-manylinux_2_31：manylinux_2_31 平台的 x86_64 目标
x86_64-manylinux_2_32：manylinux_2_32 平台的 x86_64 目标
x86_64-manylinux_2_33：manylinux_2_33 平台的 x86_64 目标
x86_64-manylinux_2_34：manylinux_2_34 平台的 x86_64 目标
x86_64-manylinux_2_35：manylinux_2_35 平台的 x86_64 目标
x86_64-manylinux_2_36：manylinux_2_36 平台的 x86_64 目标
x86_64-manylinux_2_37：manylinux_2_37 平台的 x86_64 目标
x86_64-manylinux_2_38：manylinux_2_38 平台的 x86_64 目标
x86_64-manylinux_2_39：manylinux_2_39 平台的 x86_64 目标
x86_64-manylinux_2_40：manylinux_2_40 平台的 x86_64 目标
aarch64-manylinux2014：manylinux2014 平台的 ARM64 目标。等同于 aarch64-manylinux_2_17
aarch64-manylinux_2_17：manylinux_2_17 平台的 ARM64 目标
aarch64-manylinux_2_28：manylinux_2_28 平台的 ARM64 目标
aarch64-manylinux_2_31：manylinux_2_31 平台的 ARM64 目标
aarch64-manylinux_2_32：manylinux_2_32 平台的 ARM64 目标
aarch64-manylinux_2_33：manylinux_2_33 平台的 ARM64 目标
aarch64-manylinux_2_34：manylinux_2_34 平台的 ARM64 目标
aarch64-manylinux_2_35：manylinux_2_35 平台的 ARM64 目标
aarch64-manylinux_2_36：manylinux_2_36 平台的 ARM64 目标
aarch64-manylinux_2_37：manylinux_2_37 平台的 ARM64 目标
aarch64-manylinux_2_38：manylinux_2_38 平台的 ARM64 目标
aarch64-manylinux_2_39：manylinux_2_39 平台的 ARM64 目标
aarch64-manylinux_2_40：manylinux_2_40 平台的 ARM64 目标
aarch64-linux-android：ARM64 Android 目标
x86_64-linux-android：x86_64 Android 目标
wasm32-pyodide2024：使用 Pyodide 2024 平台的 wasm32 目标。适用于 Python 3.12。参见 https://pyodide.org/en/stable/development/abi/312.html
wasm32-pyodide2025：使用 Pyodide 2025 平台的 wasm32 目标。适用于 Python 3.13。参见 https://pyodide.org/en/stable/development/abi/313.html
arm64-apple-ios：iOS 设备的 ARM64 目标
arm64-apple-ios-simulator：iOS 模拟器的 ARM64 目标
x86_64-apple-ios-simulator：iOS 模拟器的 x86_64 目标

--quiet, -q

使用静默输出。

重复此选项，例如 -qq，将启用静默模式，uv 将不会向 stdout 写入任何输出。

--refresh

刷新所有缓存数据

--refresh-package refresh-package

刷新特定包的缓存数据

--reinstall, --force-reinstall

重新安装所有包，无论它们是否已安装。隐含 --refresh

--reinstall-package reinstall-package

重新安装特定包，无论它是否已安装。隐含 --refresh-package

--resolution resolution

在给定包的不同兼容版本之间进行选择时使用的策略。

默认情况下，uv 将使用每个包的最新兼容版本（highest）。

也可以通过 UV_RESOLUTION 环境变量设置。

可能的值：

highest：解析每个包的最高兼容版本
lowest：解析每个包的最低兼容版本
lowest-direct：解析任何直接依赖项的最低兼容版本，以及任何传递依赖项的最高兼容版本

--system-certs

是否从平台的原生证书存储加载 TLS 证书 [env: UV_SYSTEM_CERTS=]

默认情况下，uv 使用捆绑的 Mozilla 根证书，这提高了可移植性和性能（尤其是在 macOS 上）。

但是，在某些情况下，您可能希望使用平台的原生证书存储，特别是当您依赖系统证书存储中包含的企业信任根（例如，用于强制代理）时。

--torch-backend torch-backend

获取 PyTorch 生态系统中的包时使用的后端（例如 cpu、cu126 或 auto）

设置后，uv 将忽略 PyTorch 生态系统中包的已配置索引 URL，转而使用定义的后端。

例如，当设置为 cpu 时，uv 将使用仅 CPU 的 PyTorch 索引；当设置为 cu126 时，uv 将使用 CUDA 12.6 的 PyTorch 索引。

auto 模式将尝试根据当前安装的 CUDA 驱动程序检测适当的 PyTorch 索引。

此选项处于预览阶段，可能在任何未来版本中发生更改。

也可以通过 UV_TORCH_BACKEND 环境变量设置。

可能的值：

auto：根据操作系统和 CUDA 驱动程序版本选择适当的 PyTorch 索引
cpu：使用仅 CPU 的 PyTorch 索引
cu130：使用 CUDA 13.0 的 PyTorch 索引
cu129：使用 CUDA 12.9 的 PyTorch 索引
cu128：使用 CUDA 12.8 的 PyTorch 索引
cu126：使用 CUDA 12.6 的 PyTorch 索引
cu125：使用 CUDA 12.5 的 PyTorch 索引
cu124：使用 CUDA 12.4 的 PyTorch 索引
cu123：使用 CUDA 12.3 的 PyTorch 索引
cu122：使用 CUDA 12.2 的 PyTorch 索引
cu121：使用 CUDA 12.1 的 PyTorch 索引
cu120：使用 CUDA 12.0 的 PyTorch 索引
cu118：使用 CUDA 11.8 的 PyTorch 索引
cu117：使用 CUDA 11.7 的 PyTorch 索引
cu116：使用 CUDA 11.6 的 PyTorch 索引
cu115：使用 CUDA 11.5 的 PyTorch 索引
cu114：使用 CUDA 11.4 的 PyTorch 索引
cu113：使用 CUDA 11.3 的 PyTorch 索引
cu112：使用 CUDA 11.2 的 PyTorch 索引
cu111：使用 CUDA 11.1 的 PyTorch 索引
cu110：使用 CUDA 11.0 的 PyTorch 索引
cu102：使用 CUDA 10.2 的 PyTorch 索引
cu101：使用 CUDA 10.1 的 PyTorch 索引
cu100：使用 CUDA 10.0 的 PyTorch 索引
cu92：使用 CUDA 9.2 的 PyTorch 索引
cu91：使用 CUDA 9.1 的 PyTorch 索引
cu90：使用 CUDA 9.0 的 PyTorch 索引
cu80：使用 CUDA 8.0 的 PyTorch 索引
rocm7.2：使用 ROCm 7.2 的 PyTorch 索引
rocm7.1：使用 ROCm 7.1 的 PyTorch 索引
rocm7.0：使用 ROCm 7.0 的 PyTorch 索引
rocm6.4：使用 ROCm 6.4 的 PyTorch 索引
rocm6.3：使用 ROCm 6.3 的 PyTorch 索引
rocm6.2.4：使用 ROCm 6.2.4 的 PyTorch 索引
rocm6.2：使用 ROCm 6.2 的 PyTorch 索引
rocm6.1：使用 ROCm 6.1 的 PyTorch 索引
rocm6.0：使用 ROCm 6.0 的 PyTorch 索引
rocm5.7：使用 ROCm 5.7 的 PyTorch 索引
rocm5.6：使用 ROCm 5.6 的 PyTorch 索引
rocm5.5：使用 ROCm 5.5 的 PyTorch 索引
rocm5.4.2：使用 ROCm 5.4.2 的 PyTorch 索引
rocm5.4：使用 ROCm 5.4 的 PyTorch 索引
rocm5.3：使用 ROCm 5.3 的 PyTorch 索引
rocm5.2：使用 ROCm 5.2 的 PyTorch 索引
rocm5.1.1：使用 ROCm 5.1.1 的 PyTorch 索引
rocm4.2：使用 ROCm 4.2 的 PyTorch 索引
rocm4.1：使用 ROCm 4.1 的 PyTorch 索引
rocm4.0.1：使用 ROCm 4.0.1 的 PyTorch 索引
xpu：使用 Intel XPU 的 PyTorch 索引

--upgrade, -U

允许包升级，忽略任何现有输出文件中的固定版本。隐含 --refresh

--upgrade-group upgrade-group

允许依赖组中所有包的升级，忽略任何现有输出文件中的固定版本

--upgrade-package, -P upgrade-package

允许特定包的升级，忽略任何现有输出文件中的固定版本。隐含 --refresh-package

--verbose, -v

使用详细输出。

您可以使用 RUST_LOG 环境变量配置细粒度日志记录。（https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#directives）

uv tool list

列出已安装的工具。

用法

uv tool list [OPTIONS]

选项

--cache-dir cache-dir

缓存目录的路径。

在 macOS 和 Linux 上默认为 $XDG_CACHE_HOME/uv 或 $HOME/.cache/uv，在 Windows 上为 %LOCALAPPDATA%\uv\cache。

要查看缓存目录的位置，请运行 uv cache dir。

也可以通过 UV_CACHE_DIR 环境变量设置。

--color color-choice

控制输出中颜色的使用。

默认情况下，uv 会在写入终端时自动检测是否支持颜色。

可能的值：

auto：仅当输出到支持颜色的终端或 TTY 时启用彩色输出
always：无论检测到的环境如何，始终启用彩色输出
never：禁用彩色输出

--config-file config-file

用于配置的 uv.toml 文件路径。

虽然 uv 配置可以包含在 pyproject.toml 文件中，但在此上下文中不允许使用。

也可以通过 UV_CONFIG_FILE 环境变量设置。

--directory directory

在运行命令之前切换到给定目录。

相对路径以给定目录为基准进行解析。

参见 --project 以仅更改项目根目录。

也可以通过 UV_WORKING_DIR 环境变量设置。

--help, -h

显示此命令的简要帮助

--no-config

避免发现配置文件（pyproject.toml、uv.toml）。

正常情况下，配置文件会在当前目录、父目录或用户配置目录中被发现。

也可以通过 UV_NO_CONFIG 环境变量设置。

--no-progress

隐藏所有进度输出 [env: UV_NO_PROGRESS=]

例如，旋转指示器或进度条。

--quiet, -q

使用静默输出。

重复此选项，例如 -qq，将启用静默模式，uv 将不会向 stdout 写入任何输出。

--show-paths

显示每个工具的安装路径

--show-version-specifiers

显示每个工具最初安装时使用的版本说明符

--verbose, -v

使用详细输出。

您可以使用 RUST_LOG 环境变量配置细粒度日志记录。（https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#directives）

uv tool uninstall

卸载已安装的工具。

用法

uv tool uninstall [OPTIONS] <NAME>...

参数

NAME: 要卸载的工具名称

选项

--all

卸载所有工具

--cache-dir cache-dir

缓存目录的路径。

在 macOS 和 Linux 上默认为 $XDG_CACHE_HOME/uv 或 $HOME/.cache/uv，在 Windows 上为 %LOCALAPPDATA%\uv\cache。

要查看缓存目录的位置，请运行 uv cache dir。

也可以通过 UV_CACHE_DIR 环境变量设置。

--color color-choice

控制输出中颜色的使用。

默认情况下，uv 会在写入终端时自动检测是否支持颜色。

可能的值：

auto：仅当输出到支持颜色的终端或 TTY 时启用彩色输出
always：无论检测到的环境如何，始终启用彩色输出
never：禁用彩色输出

--config-file config-file

用于配置的 uv.toml 文件路径。

虽然 uv 配置可以包含在 pyproject.toml 文件中，但在此上下文中不允许使用。

也可以通过 UV_CONFIG_FILE 环境变量设置。

--directory directory

在运行命令之前切换到给定目录。

相对路径以给定目录为基准进行解析。

参见 --project 以仅更改项目根目录。

也可以通过 UV_WORKING_DIR 环境变量设置。

--help, -h

显示此命令的简要帮助

--no-config

避免发现配置文件（pyproject.toml、uv.toml）。

正常情况下，配置文件会在当前目录、父目录或用户配置目录中被发现。

也可以通过 UV_NO_CONFIG 环境变量设置。

--no-progress

隐藏所有进度输出 [env: UV_NO_PROGRESS=]

例如，旋转指示器或进度条。

--quiet, -q

使用静默输出。

重复此选项，例如 -qq，将启用静默模式，uv 将不会向 stdout 写入任何输出。

--verbose, -v

使用详细输出。

您可以使用 RUST_LOG 环境变量配置细粒度日志记录。（https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#directives）

uv tool update-shell

确保 uv tool 目录在 PATH 上。如果目录不在 PATH 上，则尝试将其添加到相关的 shell 配置中。

强烈建议在安装工具后运行此命令。

不能保证 uv 对 shell 配置文件的修改总能成功，或者安全地应用。如果标准 shell 配置已有其他管理系统，或在 uv tool update-shell 失败的边缘情况下，shell 配置可能会损坏。使用 uv tool update-shell 需自行承担风险。关于 shell 配置，请查阅文档或 shell 手册。