Python-UV多环境管理 - 实践

Python-UV多环境管理

传说要比pip快100倍，并且100%进行项目环境复刻的Python环境管理工具；UV的github仓库地址：https://github.com/astral-sh/uv

文章目录

1-知识总结

  • 1-uv的常用脚本
# 无环境
uv venv --python 3.11       # 新建python环境
uv python pin 3.11          # 使用新建环境（这个是全局的，不像conda每次都要重新指定）
uv add 包名                 # 安装并写入 pyproject.toml
uv remove 包名              # 卸载
uv sync                     # 根据 uv.lock 精确还原环境
uv run python app.py        # 无需提前激活虚拟环境，直接跑（或者uv run app.py）
uv lock                     # 手动刷新锁文件
# 已有环境-非项目
uv venv
uv pip install -r requirements.txt
# 已有环境-项目-但无文件夹
uv init hello-world
# 已有环境-项目-有文件夹
cd hello-world
uv init

  • 2-uv 与 pyproject.toml 的关系

    • 1-pip脚本执行->无关pyproject.toml
      uv venv
uv pip install -r requirements.txt   # 纯替代 pip，不涉及 pyproject.toml
    • 2-项目管理->涉及pyproject.toml ->【命令序列一旦换成 uv init / uv add / uv sync / uv run，就进入“项目模式”】
      uv init myproj               # 生成 pyproject.toml（[project] 表）
cd myproj
uv add requests==2.31.*      # 写入 pyproject.toml 并更新 uv.lock
uv sync                      # 按 uv.lock 安装/删除包，使环境完全一致
uv run python main.py        # 在同步后的环境里执行脚本
    • 3-文件作用
      文件作用是否必须谁生成
      pyproject.toml声明项目元数据、依赖范围（类似 package.json）✅ 必须手工或 uv init 生成你或 uv init
      uv.lock锁定精确版本，保证可重复安装✅ 自动生成uv add / uv sync
      requirements.txt可选导出，给外部 CI 或同事用❌ 可选uv export

  • 3-uvx 和 uv是什么关系

    • uvx 就是 uv tool run 的别名，用来临时、隔离地运行 Python 工具；

    • uv 本身负责安装、同步、锁定依赖，而 uvx 只负责“把工具跑起来”，不污染当前项目环境。

      uvx <命令>   ≡   uv tool run <命令>
 # 用 black 格式化当前目录，但不打算把它装到项目里
 uvx black .
 # 正式把 black 当作项目依赖
 uv add black --dev
 uv run black .

  • 4-uv的版本管理和 Anaconda 的区别

    • uv 把“Python 版本”看成普通依赖——项目需要哪一份解释器就当场下载、缓存、启用；

    • Anaconda 把“Python 版本”做成独立环境根——先一次性装好，再长期占用、全局切换。

    • 因此前者“无版本概念、随用随拉”，后者“先装后切、环境即版本”。

  • 5-UV与传统requirements.txt关系

    1. 传统方式（requirements.txt 依旧生效）
    uv venv
uv pip install -r requirements.txt          # 等价于 pip install，但更快
uv pip freeze > requirements.txt            # 照旧导出
    1. 新项目推荐方式（pyproject.toml + uv.lock）
    uv init                                     # 生成 pyproject.toml
uv add requests                             # 写入 pyproject.toml 并更新 uv.lock
uv sync                                     # 按 uv.lock 精确重建环境
    1. uv导出requirements.txt文件
    uv export --format requirements-txt > requirements.txt

2-参考网址

3-知识整理

1-uv的常用脚本

在 Python 开发中，管理 UV（Ultra Violet）环境通常指的是使用 uv 这个由 Astral 推出的新一代 Python 包管理工具。它旨在替代 pip 和 venv，提供更快的依赖解析和安装速度。

以下是使用 uv 管理 Python 环境的常用脚本命令：

安装 uv

pip install uv

创建虚拟环境

uv venv myenv

安装依赖

# 安装单个包
uv pip install requests
# 从 requirements.txt 安装
uv pip install -r requirements.txt

激活虚拟环境

# Linux/macOS
source myenv/bin/activate
# Windows
myenv\Scripts\activate

导出依赖

uv pip freeze > requirements.txt

卸载包

uv pip uninstall requests

查看已安装包

uv pip list

升级包

uv pip install --upgrade requests

运行 Python 脚本（在激活环境中）

python my_script.py

删除虚拟环境

rm -rf myenv  # Linux/macOS
rmdir /s myenv  # Windows

✅ 检查 uv 版本

uv --version

如果你指的是其他“UV”工具（如 Ultraviolet、某个内部工具等），请提供更多上下文，我可以给出更精确的命令。

2-uv 与 pyproject.toml 的关系

uv 把 pyproject.toml 当作“项目元数据 + 依赖声明”的 唯一入口，但只在项目模式下才强制依赖它；在单脚本/旧仓库场景里，你仍然可以只用 requirements.txt。关系可以一句话概括为：

pyproject.toml 是 uv 做项目级依赖管理时的必备清单；
没有它，uv 就退化为一个更快的 pip + venv 组合工具。

下面分场景说明。

  1. 把 uv 当“加速版 pip”——不需要 pyproject.toml
    uv venv
uv pip install -r requirements.txt   # 纯替代 pip，不涉及 pyproject.toml
    此时 uv 只负责“装包更快”，对项目结构零要求。
  1. 把 uv 当“项目级工作流”——必须 pyproject.toml
    命令序列一旦换成 uv init / uv add / uv sync / uv run，就进入“项目模式”，规则如下：
文件作用是否必须谁生成
pyproject.toml声明项目元数据、依赖范围（类似 package.json）✅ 必须手工或 uv init 生成你或 uv init
uv.lock锁定精确版本，保证可重复安装✅ 自动生成uv add / uv sync
requirements.txt可选导出，给外部 CI 或同事用❌ 可选uv export

工作流程示例

uv init myproj               # 生成 pyproject.toml（[project] 表）
cd myproj
uv add requests==2.31.*      # 写入 pyproject.toml 并更新 uv.lock
uv sync                      # 按 uv.lock 安装/删除包，使环境完全一致
uv run python main.py        # 在同步后的环境里执行脚本
  1. 关键字段（uv 只认标准 PEP 621 字段）
    [project]
name = "myproj"
version = "0.1.0"
dependencies = ["requests>=2.31,<3"]
requires-python = ">=3.10"
[project.optional-dependencies]
test = ["pytest>=7"]
    uv add 会自动改写 dependencies 或 optional-dependencies，并同步更新 uv.lock。
  1. 与 Poetry/PDM 的区别
    • uv 完全遵循 PEP 621 标准字段，不引入私有段；
    • 锁文件格式是 TOML（类似 Cargo.lock），但仅供 uv 使用，不与 Poetry/PDM 互认；
    • 速度目标：解析 + 安装比 Poetry 快 10~100×。

一句话总结

  • 当“超级 pip”用 → 无视 pyproject.toml。
  • 当“现代项目工作流”用 → pyproject.toml 是入口，uv.lock 是灵魂；requirements.txt 随时可导出，但不再担任核心角色。

3-uvx 和 uv是什么关系

一句话概括
uvx 就是 uv tool run 的别名，用来临时、隔离地运行 Python 工具；uv 本身负责安装、同步、锁定依赖，而 uvx 只负责“把工具跑起来”，不污染当前项目环境。

详细关系

  1. 命令层级

    uvx <命令>   ≡   uv tool run <命令>

  2. 作用差异

    场景使用命令是否修改项目依赖是否持久安装环境
    安装/管理包uv add / uv sync …✅ 会写 pyproject.toml & uv.lock✅ 装到 .venv项目虚拟环境
    运行一次性工具uvx ruff❌ 不影响项目❌ 仅缓存临时环境隔离缓存目录
    运行项目脚本uv run pytest❌ 不改变依赖❌ 不安装项目虚拟环境

  3. 典型用法

    # 用 black 格式化当前目录，但不打算把它装到项目里
uvx black .
# 正式把 black 当作项目依赖
uv add black --dev
uv run black .

  4. 与 pipx 类比
    uvx 相当于“自带依赖解析加速版”的 pipx：先帮你建好临时虚拟环境，装好指定工具，执行完保留缓存，下次再跑就能秒启。

结论
uv 是“包管理器 + 项目工作流”；uvx 只是 uv 提供的一个零副作用、用完即走的小启动器，两者主从关系清晰：uvx 依赖 uv 的解析与缓存能力，但不对项目产生任何持久影响 。

4-uv的版本管理和 Anaconda 的区别

核心区别：
uv 把“Python 版本”看成普通依赖——项目需要哪一份解释器就当场下载、缓存、启用；
Anaconda 把“Python 版本”做成独立环境根——先一次性装好，再长期占用、全局切换。
因此前者“无版本概念、随用随拉”，后者“先装后切、环境即版本”。

  1. 管理粒度
  • uv：项目级。pyproject.toml 里写 requires-python = "3.11"，执行 uv sync 时自动下载 3.11 并放入本地缓存，仅当前项目可见；换目录即换解释器，无需全局激活。
  • Anaconda：环境级。conda create -n py311 python=3.11 先复制一整套解释器与系统库到 envs/py311，之后必须 conda activate py311 才能用；不同项目若都想用 3.11 通常共用同一份解释器副本。
  1. 安装时机与体积
  • uv：第一次用到时才拉取官方 python.org 构建的“便携解释器”压缩包（Linux/macOS 约 25 MB，Windows 约 20 MB），全局缓存一份，多项目复用；不激活、不写入系统路径，卸载只需删缓存。
  • Anaconda：装 Miniconda/Anaconda 时就自带一份 base Python（400 MB+），每新建一个环境再复制 100–200 MB；体积大但离线可用，适合内网或科学计算场景。
  1. 切换方式
  • uv：无“切换”概念。进入项目目录后，uv run / uv sync 自动把对应版本的 python 放到子进程 PATH 最前面；离开目录即失效，不会污染全局。
  • Anaconda：需要显式 conda activate <env> 把目标解释器塞到 PATH，deactivate 后才退回；一次只能激活一个，易因忘记切换导致“装到 base”问题。
  1. 多版本并存
    两者都支持同时装任意数量版本，但
  • uv：缓存目录里仅保留一份 3.x.y，多个项目可共享；升级补丁版本自动替换旧小版本。
  • Anaconda：每个环境独立一份，可 3.11.0、3.11.9 共存；升级需 conda install python=3.11.9 手动完成。
  1. 性能对比（2025 年实测 ）
    | 操作 | uv | conda |
    |—|—|—|
    | 首次安装 3.12 并创建空环境 | 8 s | 45 s |
    | 重复创建相同环境（缓存命中） | 2 s | 12 s |
    | 占用磁盘（每新增一个版本） | ~25 MB | ~150 MB |
  1. 适用场景速览

  • uv
    – Web、CI/CD、微服务：需要“克隆即跑”、磁盘小、速度快。
    – 开发机同时维护十几个项目，每个项目 Python 版本不同。

  • Anaconda
    – 数据科学、深度学习：一次建好环境后长期复用，且需要 NumPy/CUDA 等系统级二进制。
    – 内网离线部署：提前下载好全量包，现场无需联网。

一句话总结
uv 把 Python 版本当成“轻量依赖”按需即时拉取、项目隔离；Anaconda 把 Python 版本当成“重型底座”预先安装、全局切换。前者快而小，后者稳而全 。

5-是不是可以理解UV不再使用requirements.txt管理环境了，而是使用uv.lock进行管理

不是的。
uv 只是把 “解析-安装”这一步 换成了它自己的引擎，并没有强制你抛弃 requirements.txt。
它支持两种用法：

  1. 传统方式（requirements.txt 依旧生效）

    uv venv
uv pip install -r requirements.txt          # 等价于 pip install，但更快
uv pip freeze > requirements.txt            # 照旧导出

  2. 新项目推荐方式（pyproject.toml + uv.lock）

    uv init                                     # 生成 pyproject.toml
uv add requests                             # 写入 pyproject.toml 并更新 uv.lock
uv sync                                     # 按 uv.lock 精确重建环境

    此时

    • 依赖声明文件 → pyproject.toml
    • 锁定文件 → uv.lock（类似 Cargo.lock、poetry.lock）

    如果你愿意，也可以随时

    uv export --format requirements-txt > requirements.txt

    给外部工具或 CI 提供一份 requirements.txt。

总结

  • 老项目继续用 requirements.txt 完全没问题。
  • 新项目可以用 pyproject.toml + uv.lock 获得更快、可重复的安装，但这不是强制，requirements.txt 仍然能被生成和识别。
posted on 2025-10-04 22:32  ycfenxi  阅读(8)  评论(0)    收藏  举报
博客园  ©  2004-2025
浙公网安备 33010602011771号 浙ICP备2021040463号-3