uv

一个极速的Python包安装器和解析器，用Rust编写。旨在作为常见pip和pip-tools工作流程的直接替代品。

显示基准测试结果的条形图。

使用热缓存安装Trio依赖。

亮点

⚖️ 可直接替代常见的pip、pip-tools和virtualenv命令。
⚡️ 比pip和pip-tools（pip-compile和pip-sync）快10-100倍。
💾 磁盘空间利用率高，使用全局缓存实现依赖去重。
🐍 可通过curl、pip、pipx等方式安装。uv是一个静态二进制文件，无需Rust或Python即可安装。
🧪 在前10,000个PyPI包上进行了大规模测试。
🖥️ 支持macOS、Linux和Windows。
🧰 提供高级功能，如依赖版本覆盖和替代解析策略。
⁉️ 使用冲突跟踪解析器，提供同类最佳的错误信息。
🤝 支持广泛的高级pip功能，包括可编辑安装、Git依赖、直接URL依赖、本地依赖、约束条件、源代码分发、HTML和JSON索引等。

uv由Astral（Ruff的创建者）支持。

入门

使用我们的独立安装程序或从PyPI安装uv：

# 在macOS和Linux上。
curl -LsSf https://astral.sh/uv/install.sh | sh

# 在Windows上。
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

# 安装特定版本。
curl -LsSf https://astral.sh/uv/0.2.37/install.sh | sh
powershell -c "irm https://astral.sh/uv/0.2.37/install.ps1 | iex"

# 使用pip安装。
pip install uv

# 使用pipx安装。
pipx install uv

# 使用Homebrew安装。
brew install uv

创建虚拟环境：

uv venv  # 在`.venv`创建虚拟环境。

激活虚拟环境：

# 在macOS和Linux上。
source .venv/bin/activate

# 在Windows上。
.venv\Scripts\activate

在虚拟环境中安装包：

uv pip install flask                # 安装Flask。
uv pip install -r requirements.txt  # 从requirements.txt文件安装。
uv pip install -e .                 # 以可编辑模式安装当前项目。
uv pip install "package @ ."        # 从磁盘安装当前项目。
uv pip install "flask[dotenv]"      # 安装Flask，包含"dotenv"额外功能。

生成锁定的依赖集：

uv pip compile requirements.in -o requirements.txt    # 读取requirements.in文件。
uv pip compile pyproject.toml -o requirements.txt     # 读取pyproject.toml文件。
uv pip compile setup.py -o requirements.txt           # 读取setup.py文件。
echo flask | uv pip compile - -o requirements.txt     # 从标准输入读取。
uv pip freeze | uv pip compile - -o requirements.txt  # 锁定当前环境。

将锁定的依赖集同步到虚拟环境：

uv pip sync requirements.txt  # 从requirements.txt文件安装。

uv的pip-install和pip-compile命令支持许多与现有工具相同的命令行参数，包括-r requirements.txt、-c constraints.txt、-e .（用于可编辑安装）、--index-url等。

局限性

虽然uv支持pip接口的大部分功能，但并不支持全部功能。在某些情况下，这些差异是有意为之的；在其他情况下，则是由于uv处于早期开发阶段所致。

详情请参阅我们的pip兼容性指南。

与pip-compile类似，uv生成特定平台的requirements.txt文件（不同于poetry和pdm，它们生成平台无关的poetry.lock和pdm.lock文件）。因此，uv的requirements.txt文件可能无法在不同平台和Python版本间移植。

路线图

uv是一个极速的Python包解析器和安装器，旨在替代pip、pip-tools（pip-compile和pip-sync）以及virtualenv。

uv代表了我们追求"Python版Cargo"的中间目标：一个全面的项目和包管理器，具有极快的速度、可靠性和易用性。

设想一下：一个单一的二进制文件，可以引导您的Python安装，并提供所有您需要的Python生产力工具，不仅包括pip、pip-tools和virtualenv，还包括pipx、tox、poetry、pyenv、ruff等。

我们的目标是将uv发展成为这样一个工具。

同时，更窄的pip-tools范围允许我们解决构建此类工具所涉及的底层问题（如包安装），同时提供立即可用且采用门槛极低的解决方案。

高级用法

Python发现

uv本身不依赖Python，但它需要定位Python环境以(1)将依赖安装到环境中，以及(2)构建源代码分发。

运行pip sync或pip install时，uv将按以下顺序搜索虚拟环境：

基于VIRTUAL_ENV环境变量的已激活虚拟环境。
基于CONDA_PREFIX环境变量的已激活Conda环境。
当前目录或最近的父目录中.venv下的虚拟环境。

如果未找到虚拟环境，uv将提示用户通过uv venv在当前目录中创建一个。运行 pip compile 时，uv 并不强制要求虚拟环境，它会按以下顺序搜索 Python 解释器：

基于 VIRTUAL_ENV 环境变量的已激活虚拟环境。
基于 CONDA_PREFIX 环境变量的已激活 Conda 环境。
当前目录或最近的父目录中的 .venv 虚拟环境。
在 macOS 和 Linux 上可用as python3 的 Python 解释器，或在 Windows 上的 python.exe。

如果为 pip compile 提供了 --python-version（例如 --python-version=3.7），uv 将按以下顺序搜索匹配该版本的 Python 解释器：

基于 VIRTUAL_ENV 环境变量的已激活虚拟环境。
基于 CONDA_PREFIX 环境变量的已激活 Conda 环境。
当前目录或最近的父目录中的 .venv 虚拟环境。
在 macOS 和 Linux 上可用as（例如）python3.7 的 Python 解释器。
在 macOS 和 Linux 上可用as python3 的 Python 解释器，或在 Windows 上的 python.exe。
在 Windows 上，通过 py --list-paths 返回的匹配请求版本的 Python 解释器。

安装到任意 Python 环境

由于 uv 不依赖 Python，它可以安装到自身以外的虚拟环境中。例如，设置 VIRTUAL_ENV=/path/to/venv 将使 uv 安装到 /path/to/venv，无论 uv 安装在哪里。请注意，如果 VIRTUAL_ENV 设置为不符合 PEP 405 的虚拟环境目录，它将被忽略。

uv 还可以通过为 uv pip sync 或 uv pip install 提供 --python 参数来安装到任意环境，甚至非虚拟环境。例如，uv pip install --python=/path/to/python 将安装到与 /path/to/python 解释器链接的环境中。

为方便起见，uv pip install --system 将安装到系统 Python 环境中。使用 --system 大致相当于 uv pip install --python=$(which python)，但请注意，链接到虚拟环境的可执行文件将被跳过。尽管我们通常建议使用虚拟环境进行依赖管理，但 --system 适用于持续集成和容器化环境。

--system 标志还用于选择修改系统环境。例如，可以使用 --python 参数请求特定的 Python 版本（如 --python 3.12），uv 将搜索满足该请求的解释器。如果 uv 找到系统解释器（例如 /usr/lib/python3.12），则需要 --system 标志来允许修改这个非虚拟 Python 环境。没有 --system 标志，uv 将忽略任何不在虚拟环境中的解释器。相反，提供 --system 标志时，uv 将忽略任何处于虚拟环境中的解释器。

在不同平台和发行版上安装到系统 Python 是出了名的困难。uv 支持常见情况，但并非在所有情况下都有效。例如，由于发行版对 distutils 的修补（但未修补 sysconfig），在 Python 3.10 之前的 Debian 上安装到系统 Python 是不支持的。虽然我们始终建议使用虚拟环境，但 uv 认为在这些非标准环境中，虚拟环境是必需的。

如果 uv 安装在 Python 环境中（例如通过 pip 安装），它仍然可以用于修改其他环境。但是，当通过 python -m uv 调用时，uv 默认使用父解释器的环境。通过 Python 调用 uv 会增加启动开销，不建议常规使用。

持久配置

uv 支持项目级和用户级的持久配置。

具体来说，uv 将在当前目录或最近的父目录中搜索 pyproject.toml 或 uv.toml 文件。

如果找到 pyproject.toml 文件，uv 将从 [tool.uv.pip] 表中读取配置。例如，要设置持久的索引 URL，可以在 pyproject.toml 中添加以下内容：

[tool.uv.pip]
index-url = "https://test.pypi.org/simple"

（如果没有这样的表，pyproject.toml 文件将被忽略，uv 将继续在目录层次结构中搜索。）

如果找到 uv.toml 文件，uv 将从 [pip] 表中读取。例如：

[pip]
index-url = "https://test.pypi.org/simple"

uv 还会在 macOS 和 Linux 上的 ~/.config/uv/uv.toml（或 $XDG_CONFIG_HOME/uv/uv.toml），或 Windows 上的 %APPDATA%\uv\uv.toml 发现用户级配置。用户级配置必须使用 uv.toml 格式，而不是 pyproject.toml 格式，因为 pyproject.toml 旨在定义 Python 项目。

如果同时找到项目级和用户级配置，设置将被合并，项目级配置优先。具体来说，如果字符串、数字或布尔值同时出现在两个表中，将使用项目级值，忽略用户级值。如果数组同时出现在两个表中，数组将被连接，项目级设置在合并后的数组中出现较早。

通过环境变量提供的设置优先于持久配置，通过命令行提供的设置优先于两者。

uv 接受 --no-config 命令行参数，提供时将禁用任何持久配置的发现。

uv 还接受 --config-file 命令行参数，它接受一个 uv.toml 文件的路径作为配置文件。提供时，此文件将替代任何发现的配置文件（例如，用户级配置将被忽略）。

Git 认证

uv 允许从 Git 安装包，并支持以下方案来对私有仓库进行认证。

使用 SSH：

git+ssh://git@<hostname>/...（例如 git+ssh://git@github.com/astral-sh/uv）
git+ssh://git@<host>/...（例如 git+ssh://git@github.com-key-2/astral-sh/uv）

有关如何配置 SSH 的更多详细信息，请参阅 GitHub SSH 文档。

使用密码或令牌：

git+https://<user>:<token>@<hostname>/...（例如 git+https://git:github_pat_asdf@github.com/astral-sh/uv）
git+https://<token>@<hostname>/...（例如 git+https://github_pat_asdf@github.com/astral-sh/uv）
git+https://<user>@<hostname>/...（例如 git+https://git@github.com/astral-sh/uv）

使用 GitHub 个人访问令牌时，用户名是任意的。GitHub 不支持直接使用密码登录，但其他主机可能支持。如果提供了用户名但没有凭据，系统会提示您输入凭据。

如果 URL 中没有凭据但需要认证，uv 将查询 Git 凭据助手。

HTTP 认证

uv 在查询包注册表时支持 HTTP 凭据。

认证可以来自以下来源，按优先级顺序：

URL，例如 https://<user>:<password>@<hostname>/...
netrc 配置文件
keyring 提供程序（需要选择加入）

如果为单个网络位置（方案、主机和端口）找到认证，它将在命令执行期间被缓存，并用于对该网络位置的其他查询。认证不会在 uv 的多次调用之间缓存。

注意，必须提供 --keyring-provider subprocess 或 UV_KEYRING_PROVIDER=subprocess 以启用基于 keyring 的认证。

认证可用于以下上下文中指定的主机：

index-url
extra-index-url
find-links
package @ https://...

有关与pip的差异详情，请参阅pip兼容性指南。

依赖缓存

uv使用积极的缓存策略，以避免重新下载（和重新构建）先前运行中已访问过的依赖项。

uv的缓存语义具体取决于依赖项的性质：

对于注册表依赖项（如从PyPI下载的依赖项），uv遵循HTTP缓存头。
对于直接URL依赖项，uv遵循HTTP缓存头，并基于URL本身进行缓存。
对于Git依赖项，uv基于完全解析的Git提交哈希进行缓存。因此，uv pip compile在写入已解析的依赖集时，会将Git依赖项固定到特定的提交哈希。
对于本地依赖项，uv基于源档案（即本地的.whl或.tar.gz文件）的最后修改时间进行缓存。对于目录，uv基于pyproject.toml、setup.py或setup.cfg文件的最后修改时间进行缓存。

可以安全地并发运行多个uv命令，即使是针对同一虚拟环境。uv的缓存设计为线程安全和仅追加，因此能够应对多个并发读取器和写入器。在安装时，uv对目标虚拟环境应用基于文件的锁定，以避免跨进程的并发修改。

请注意，在其他uv命令运行时直接修改uv缓存（例如，uv cache clean）是不安全的，而且直接修改缓存（例如，删除文件或目录）永远是不安全的。

如果遇到缓存问题，uv提供了一些应急方案：

要强制uv重新验证所有依赖项的缓存数据，运行uv pip install --refresh ...。
要强制uv重新验证特定依赖项的缓存数据，运行uv pip install --refresh-package flask ...。
要强制uv忽略现有的已安装版本，运行uv pip install --reinstall ...。
要完全清除全局缓存，运行uv cache clean。

解析策略

默认情况下，uv遵循标准Python依赖解析策略，优先选择每个包的最新兼容版本。例如，uv pip install flask>=2.0.0将安装Flask的最新版本（撰写时为3.0.0）。

然而，uv的解析策略可以配置以支持替代工作流程。使用--resolution=lowest时，uv将为所有依赖项安装最低兼容版本，包括直接和传递依赖项。另外，--resolution=lowest-direct将为所有直接依赖项选择最低兼容版本，同时为所有传递依赖项使用最新兼容版本。这种区分对于希望测试直接依赖项的最低支持版本而不限制传递依赖项版本的库作者特别有用。

例如，给定以下requirements.in文件：

flask>=2.0.0

运行uv pip compile requirements.in将生成以下requirements.txt文件：

# 此文件由uv通过以下命令自动生成：
#    uv pip compile requirements.in
blinker==1.7.0
    # 来自 flask
click==8.1.7
    # 来自 flask
flask==3.0.0
itsdangerous==2.1.2
    # 来自 flask
jinja2==3.1.2
    # 来自 flask
markupsafe==2.1.3
    # 来自
    #   jinja2
    #   werkzeug
werkzeug==3.0.1
    # 来自 flask

然而，uv pip compile --resolution=lowest requirements.in将生成：

# 此文件由uv通过以下命令自动生成：
#    uv pip compile requirements.in --resolution=lowest
click==7.1.2
    # 来自 flask
flask==2.0.0
itsdangerous==2.0.0
    # 来自 flask
jinja2==3.0.0
    # 来自 flask
markupsafe==2.0.0
    # 来自 jinja2
werkzeug==2.0.0
    # 来自 flask

预发布版本处理

默认情况下，uv在依赖解析期间会在两种情况下接受预发布版本：

如果包是直接依赖项，并且其版本标记包含预发布指定符（例如，flask>=2.0.0rc1）。
如果包的所有已发布版本都是预发布版本。

如果由于传递预发布版本导致依赖解析失败，uv将提示用户使用--prerelease=allow重新运行，以允许所有依赖项使用预发布版本。

或者，您可以将传递依赖项添加到requirements.in文件中，并使用预发布指定符（例如，flask>=2.0.0rc1）来选择支持该特定依赖项的预发布版本。

预发布版本众所周知很难建模，并且是其他打包工具中常见的错误源。uv的预发布处理是有意受限的，并且有意要求用户选择使用预发布版本，以确保正确性。

更多信息，请参见"预发布兼容性"

依赖覆盖

历史上，pip支持"约束"（-c constraints.txt），允许用户缩小给定包的可接受版本集。

uv支持约束，但还进一步允许用户通过覆盖（--override overrides.txt）来覆盖依赖树中包的可接受版本。

简而言之，覆盖允许用户通过覆盖包的声明依赖来"欺骗"解析器。覆盖是一种有用的最后手段，适用于用户知道依赖项与包的较新版本兼容，但包尚未更新以声明该兼容性的情况。

例如，如果传递依赖项声明pydantic>=1.0,<2.0，但用户知道该包与pydantic>=2.0兼容，用户可以用pydantic>=2.0,<3覆盖声明的依赖，以允许解析器继续。

虽然约束纯粹是附加的，因此不能扩大包的可接受版本集，但覆盖可以扩大包的可接受版本集，为错误的上限版本提供一个应急方案。

平台无关的解析

默认情况下，uv的pip-compile命令生成已知与当前平台和Python版本兼容的解析结果。与Poetry和PDM不同，uv尚未生成与机器无关的锁文件（#2679）。

然而，uv确实支持通过--python-platform和--python-version命令行参数为其他平台和Python版本进行解析。

例如，如果您在macOS上运行uv，但想为Linux解析，可以运行uv pip compile --python-platform=linux requirements.in以生成与manylinux2014兼容的解析结果。

同样，如果您在Python 3.9上运行uv，但想为Python 3.8解析，可以运行uv pip compile --python-version=3.8 requirements.in以生成与Python 3.8兼容的解析结果。

--python-platform和--python-version参数可以组合使用，为特定平台和Python版本生成解析结果，使用户能够从单一机器为不同环境生成多个锁文件。

注意：Python的环境标记暴露了比简单的--python-platform参数所能表达的更多当前机器信息。例如，macOS上的platform_version标记包括内核构建时间，这（理论上）可以编码在包需求中。uv的解析器尽最大努力生成与目标--python-platform上运行的任何机器兼容的解析结果，这对大多数用例应该足够，但对于复杂的包和平台组合可能会失去一些精度。

时间限制的可重现解析

uv 支持 --exclude-newer 选项，可以限制解析仅包含特定日期之前发布的分发包，从而允许重现安装，而不受新包发布的影响。日期可以指定为 RFC 3339 时间戳（例如 2006-12-02T02:07:43Z）或相同格式的 UTC 日期（例如 2006-12-02）。

请注意，包索引必须支持 PEP 700 中规定的 upload-time 字段。如果某个分发包没有该字段，则该分发包将被视为不可用。

为确保可重现性，无法满足的解析消息不会提及由于 --exclude-newer 标志而排除了分发包 — 较新的分发包将被视为不存在。

自定义 CA 证书

默认情况下，uv 从捆绑的 webpki-roots crate 加载证书。webpki-roots 是来自 Mozilla 的可靠信任根集合，将其包含在 uv 中可以提高可移植性和性能（尤其是在 macOS 上，读取系统信任存储会导致显著延迟）。

然而，在某些情况下，您可能希望使用平台的原生证书存储，特别是如果您依赖包含在系统证书存储中的公司信任根（例如，用于强制代理）。要指示 uv 使用系统的信任存储，请使用 --native-tls 命令行标志运行 uv，或将 UV_NATIVE_TLS 环境变量设置为 true。

如果需要证书的直接路径（例如在 CI 中），请将 SSL_CERT_FILE 环境变量设置为证书包的路径，以指示 uv 使用该文件而不是系统的信任存储。

如果需要客户端证书认证（mTLS），请将 SSL_CLIENT_CERT 环境变量设置为包含证书后跟私钥的 PEM 格式文件的路径。

平台支持

uv 对以下平台提供 Tier 1 支持：

macOS（Apple Silicon）
macOS（x86_64）
Linux（x86_64）
Windows（x86_64）

uv 在其 Tier 1 平台上持续构建、测试和开发。受 Rust 项目启发，Tier 1 可以被理解为"保证可用"。

uv 对以下平台提供 Tier 2 支持（"保证可构建"）：

Linux（PPC64）
Linux（PPC64LE）
Linux（aarch64）
Linux（armv7）
Linux（i686）
Linux（s390x）

uv 为其 Tier 1 和 Tier 2 平台在 PyPI 上提供预构建的 wheel。然而，虽然 Tier 2 平台持续构建，但并不持续测试或开发，因此实际稳定性可能会有所不同。

除了 Tier 1 和 Tier 2 平台之外，uv 已知可以在 i686 Windows 上构建，但已知在 aarch64 Windows 上无法构建，目前不考虑支持这两个平台。支持的最低 Windows 版本是 Windows 10，遵循 Rust 自身的 Tier 1 支持。

uv 支持并测试了 Python 3.8、3.9、3.10、3.11 和 3.12 版本。

环境变量

uv 接受以下命令行参数作为环境变量：

UV_INDEX_URL：等同于 --index-url 命令行参数。如果设置，uv 将使用此 URL 作为搜索包的基本索引。
UV_EXTRA_INDEX_URL：等同于 --extra-index-url 命令行参数。如果设置，uv 将使用此空格分隔的 URL 列表作为搜索包时的附加索引。
UV_CACHE_DIR：等同于 --cache-dir 命令行参数。如果设置，uv 将使用此目录进行缓存，而不是默认缓存目录。
UV_NO_CACHE：等同于 --no-cache 命令行参数。如果设置，uv 将不使用缓存进行任何操作。
UV_RESOLUTION：等同于 --resolution 命令行参数。例如，如果设置为 lowest-direct，uv 将安装所有直接依赖的最低兼容版本。
UV_PRERELEASE：等同于 --prerelease 命令行参数。例如，如果设置为 allow，uv 将允许所有依赖项使用预发布版本。
UV_SYSTEM_PYTHON：等同于 --system 命令行参数。如果设置为 true，uv 将使用系统 PATH 中找到的第一个 Python 解释器。警告：UV_SYSTEM_PYTHON=true 旨在用于持续集成（CI）或容器化环境，应谨慎使用，因为修改系统 Python 可能导致意外行为。
UV_PYTHON：等同于 --python 命令行参数。如果设置为路径，uv 将使用此 Python 解释器进行所有操作。
UV_BREAK_SYSTEM_PACKAGES：等同于 --break-system-packages 命令行参数。如果设置为 true，uv 将允许安装与系统安装包冲突的包。警告：UV_BREAK_SYSTEM_PACKAGES=true 旨在用于持续集成（CI）或容器化环境，应谨慎使用，因为修改系统 Python 可能导致意外行为。
UV_NATIVE_TLS：等同于 --native-tls 命令行参数。如果设置为 true，uv 将使用系统的信任存储而不是捆绑的 webpki-roots crate。
UV_INDEX_STRATEGY：等同于 --index-strategy 命令行参数。例如，如果设置为 unsafe-any-match，uv 将考虑所有索引 URL 中给定包的可用版本，而不是将搜索限制在包含该包的第一个索引 URL。
UV_REQUIRE_HASHES：等同于 --require-hashes 命令行参数。如果设置为 true，uv 将要求所有依赖项在需求文件中指定哈希值。
UV_CONSTRAINT：等同于 --constraint 命令行参数。如果设置，uv 将使用此文件作为约束文件。使用空格分隔的文件列表。
UV_BUILD_CONSTRAINT：等同于 --build-constraint 命令行参数。如果设置，uv 将使用此文件作为任何源分发包构建的约束。使用空格分隔的文件列表。
UV_OVERRIDE：等同于 --override 命令行参数。如果设置，uv 将使用此文件作为覆盖文件。使用空格分隔的文件列表。
UV_LINK_MODE：等同于 --link-mode 命令行参数。如果设置，uv 将使用此作为链接模式。
UV_NO_BUILD_ISOLATION：等同于 --no-build-isolation 命令行参数。如果设置，uv 在构建源分发包时将跳过隔离。
UV_CUSTOM_COMPILE_COMMAND：等同于 --custom-compile-command 命令行参数。用于在 uv pip compile 生成的 requirements.txt 文件的输出头部覆盖 uv。旨在用于从包装脚本内调用 uv pip compile 的用例，以在输出文件中包含包装脚本的名称。
UV_KEYRING_PROVIDER：等同于 --keyring-provider 命令行参数。如果设置，uv 将使用此值作为密钥环提供者。
UV_CONFIG_FILE：等同于 --config-file 命令行参数。期望设置为本地 uv.toml 文件的路径，用作配置文件。
UV_NO_CONFIG：等同于 --no-config 命令行参数。如果设置，uv 将不读取当前目录、父目录或用户配置目录中的任何配置文件。
UV_EXCLUDE_NEWER：等同于 --exclude-newer 命令行参数。如果设置，uv 将排除在指定日期之后发布的分发包。

在每种情况下，相应的命令行参数优先于环境变量。

此外，uv 还遵循以下环境变量：

UV_CONCURRENT_DOWNLOADS：设置uv在任何给定时间执行的最大并发下载数。
UV_CONCURRENT_BUILDS：设置uv在任何给定时间并发构建的最大源代码分发数。
UV_CONCURRENT_INSTALLS：用于控制安装和解压包时使用的线程数。
UV_TOOL_DIR：用于指定uv存储管理工具的目录。
UV_PYTHON_INSTALL_DIR：用于指定uv存储管理的Python安装的目录。
UV_PYTHON_INSTALL_MIRROR：管理的Python安装从python-build-standalone下载。此变量可设置为镜像URL，以使用不同的Python安装源。提供的URL将替换https://github.com/indygreg/python-build-standalone/releases/download，例如在https://github.com/indygreg/python-build-standalone/releases/download/20240713/cpython-3.12.4%2B20240713-aarch64-apple-darwin-install_only.tar.gz中。
UV_PYPY_INSTALL_MIRROR：管理的PyPy安装从python.org下载。此变量可设置为镜像URL，以使用不同的PyPy安装源。提供的URL将替换https://downloads.python.org/pypy，例如在https://downloads.python.org/pypy/pypy3.8-v7.3.7-osx64.tar.bz2中。
XDG_CONFIG_HOME：用于指定Linux和macOS系统上uv用户级配置目录的路径。
XDG_CACHE_HOME：用于指定uv在Linux系统上存储缓存文件的目录。
XDG_DATA_HOME：用于指定uv在Linux系统上存储管理的Python安装和管理工具的目录。
XDG_BIN_HOME：用于指定安装可执行文件的目录。
SSL_CERT_FILE：如果设置，uv将使用此文件作为证书包，而不是系统的信任存储。
SSL_CLIENT_CERT：如果设置，uv将使用此文件进行mTLS认证。这应该是一个包含PEM格式的证书和私钥的单个文件。
RUST_LOG：如果设置，uv将使用此值作为其--verbose输出的日志级别。接受与tracing_subscriber包兼容的任何过滤器。例如，RUST_LOG=trace将启用跟踪级别的日志记录。更多信息请参见tracing文档。
HTTP_PROXY、HTTPS_PROXY、ALL_PROXY：用于所有HTTP/HTTPS请求的代理。
HTTP_TIMEOUT（或UV_HTTP_TIMEOUT）：如果设置，uv将使用此值（以秒为单位）作为HTTP读取的超时时间（默认：30秒）。
PYC_INVALIDATION_MODE：与--compile一起运行时使用的验证模式。参见：PycInvalidationMode。
VIRTUAL_ENV：用于检测激活的虚拟环境。
CONDA_PREFIX：用于检测激活的Conda环境。
PROMPT：用于检测Windows命令提示符的使用（而非PowerShell）。
NU_VERSION：用于检测NuShell的使用。
FISH_VERSION：用于检测Fish shell的使用。
BASH_VERSION：用于检测Bash shell的使用。
ZSH_VERSION：用于检测Zsh shell的使用。
MACOSX_DEPLOYMENT_TARGET：与--python-platform macos及相关变体一起使用，设置部署目标（即最低支持的macOS版本）。默认为12.0，即撰写时最近的非EOL macOS版本。
NO_COLOR：禁用颜色。优先于FORCE_COLOR。参见no-color.org。
FORCE_COLOR：无论TTY支持如何，都强制使用颜色。参见force-color.org。