别纠结了跟着这个流程走首先, 你所从事的是深度学习或者科学计算方面的工作, 那么请问, 是否需要用到CUDA或者非库呢?第二步你是在维护一个 10 年以上的老项目吗第三步: 直接采用 uv, 并不需要 pyenv, 也不需要 , 更不需要 pip-tools, 直接达成效果。用一句话概括我的提议, 那便是, 要先尝试 uv, 仅在这种场景里面, 也就是 uv 无法处理搞定的场景主要是那些并非依赖的情况, 才去引入 conda, 而此策略所具备的风险基本算得上是零, 这是由于从 uv 转回传统工具链是极为简单易做的。5 分钟上手从安装到跑项目提及了这般诸多内容, 反倒不如径直着手操作。以下呈现的是自起始之际运用uv的整个完整流程。安装 uv# macOS / Linux curl -LsSf https://astral.sh/uv/install.sh | sh # Windows PowerShell powershell -ExecutionPolicy ByPass -c irm https://astral.sh/uv/install.ps1 | iex # 如果你已经有 pip但我不推荐这种方式 pip install uv系统完成安装之后, uv这个命令便能够开始使用了。并不需要对终端进行重新启动, 并且也不需要去进行环境变量的配置, 这便是uv所拥有的设计哲学, 也就是要去减少所有一切并非必要的摩擦。场景一创建新项目uv init my-project # 创建项目自动生成 pyproject.toml cd my-project uv add flask requests # 添加依赖自动创建虚拟环境和 lock file uv run python app.py # 在虚拟环境中运行通过三条命令, 项目便运行起来了。相较于传统流程: 先是执行 -m venv .venv , 接着执行 .venv/bin/ , 再次执行 pip flask , 然后执行 pip 并将其输出重定向到 .txt , 最后执行 app.py——传统流程需要五条命令, 而且还得手动对 .txt 进行管理。场景二指定 版本uv python install 3.12 # 下载 Python 3.122-3 秒 uv init --python 3.12 my-project # 用 3.12 创建项目与 pyenv 作对比: pyenv 为 3.12.0 版本, 编译过程需三至五分钟, 存在因缺少库文件而报错的可能性, 之后执行 pyenv local 3.12.0 操作, 此为设置目录级别的版本, 随后还需要自行去创建虚拟环境。场景三运行一次性工具uvx ruff check . # 不用安装直接跑 ruff 代码检查 uvx black . # 直接跑 black 格式化 uvx jupyter lab # 直接启动 Jupyter Labuvx 与 pipx run 等效, 其具备下载、运行功能, 且不会对全局环境造成污染。然而, uvx 的速度更快, 原因在于它拥有全局缓存。场景四从现有 .txt 迁移uv init my-project cd my-project uv add -r requirements.txt # 导入现有依赖 uv sync # 安装并生成 lock file迁移就是这么简单。原来的 .txt 还在随时可以回退。说说 uv 不能做的事只讲好话的评测文章不是我在所乐意具有喜好的对象。uv的确是具备着优异杰出的特质, 然而以下这些场景你是应当获悉知晓它存在的局限之处的:并非依赖, 这可是最大的缺口。要是你的项目需要CUDA, 或者cuDNN, 又或者任何C/C系统库, uv是没法帮到你的。conda的核心价值并非是包管理, 而是它能够把像CUDA 11.8以及cuDNN 8.9这种系统级依赖打包成跨平台的conda包。在这一点上uv是完全没办法替代的。实操建议是, 用conda专门负责系统级依赖, 而包则全都交给uv。企业内部网络环境是需要进行验证的, 要是你处于银行、政府等那些需要经过安全审批的环境里工作, uv当下还并未发布v1.0正式版本最新的版本是v0.11.x, 部分企业的采购流程会受困于版本号之上。此外, uv的离线模式功能是不是还不够完善呀, 在完全处于断网的环境之中或许会遭遇问题的。磁盘空间会被缓存占用, 有用户讲使用一年之后缓存超出20GB, 虽说uv cache clean一条指令就能进行清理, 可是在磁盘内存紧张的CI机器上要加以留意。尚不支持uv.lock, 要是你的安全流程依赖扫描依赖漏洞, 而当前uv的lock file格式未获支持这对安全要求高的生产项目而言是个实际障碍。受到 VC 支持的公司, 这构成了一个存在争议的要点。uv 是经由公司进行开发的, 并且获取了风投。有人会担忧在未来是否会遭遇商业化绑架的情况。而我的观点是, uv 是依据 MIT 协议实现开源的, 即便出现策略方面的变化, 社区能够进行 fork。并且其同时还维护着 Ruff速度最快的那个, 他们于开源社区当前所拥有的信誉是呈正面态势的。此风险固然存在, 然而却不应当成为你不使用 uv 的缘由。给不同角色的具体建议刚接触的新手: 直接采用uv 来操作, 千万别去触碰pip 加上 pyenv的这种组合。你的人生没必要花费两小时去配置环境。uv进行初始化操作, uv添加相关内容, uv运行程序, 通过这三步就能完成。拥有网络开发能力的人员: 要全面实现uv的切换。Flask这个项目, 它完全是处于uv所具备的能力范畴之内的。uv.lock能够确保在部署环境当中, 再也不会出现那种“在我自己的机器上是能够运行的”这种状况。专注做数据的科学家提出: 采用的是 conda 与 uv 相混合的一种方案, 先是运用 conda 去安装 以及 CUDA 系统所需要的依赖, 尔后通过 uv 借助 pip 来管理 包, 这种办法相较于单纯运用 conda 来安装包要快出许多。针对CI工程师而言, 这是uv收益最为可观的场景, CI流水线每日会运行几十至上百次构建, uv的并行下载以及缓存机制乃提升性能的突出优势 , 于此场景中运用uv取代pip可是我极力推荐的改进举措哟。写在最后包管理所处的那种乱糟糟的状况维持了长达十几年, pip、、pyenv、pip - tools、、、conda各有各的用处——每个工具都只是处理了其中一小部分问题, 然而却没有任何一个工具能够让你仅仅学习这一个工具, 便可以将所有相关事务都妥妥解决。uv可算是首个能确实达成此事的工具, 它并非是如再一个“更出色的pip”那般, 而是将包管理本该附带的种种能力全部汇聚于一种统一的, 同时极为迅速的体验之中。我的提议十分简洁: 首先尝试uv, 要是它无法化解你的难题这类情况极为罕见, 接着再度回归你原先所运用的工具, 迁移所需成本近乎为零, 然而收益在瞬间便能显现出来。