Python 工程管理的发展史

0 阅读5分钟

为什么管理工具乱成一团

Python 的包管理、环境隔离和工程管理生态确实出了名的混乱。感到迷茫是非常正常的——Python 社区甚至有过一张著名的 xkcd 漫画,专门吐槽大家电脑里错综复杂的 Python 环境。

image.png ^[skcd.com]

这种混乱的根源在于:Python 诞生太早了(1991年)。它诞生时,世界上还没有“现代包管理器”(如 npm, cargo)的概念。现在的生态是几十年不断打补丁、演进、以及 “官方工作组”、“商业公司”和“民间大神”三足鼎立、互相博弈 的结果。

我们要解决的宏观问题

  • Python 版本管理:不同项目可能需要不同的 Python 解释器版本,把不同版本的 Python 解释器当作普通的软件一样隔离开来安装。pyenv, uv
  • 三方库依赖管理:不同项目有不同依赖,需要虚拟环境进行隔离。venv, virtualenv
  • 依赖关系解析与版本锁定:依赖包的版本不一,引入依赖锁(Lock file),记录精确版本号(hash),保证每个人装的 100% 一样。PoetryPDMuvpip-tools
  • 代码构建,打包与分发配置:制定统一的工程元数据标准,提供一键构建和发布的指令。setuptools(过去)、HatchPoetryPDM(现在)

发展历史

一、 远古时代(2008年以前):混沌初开

  • 发起者:早期 Python 核心开发者与松散的社区。
  • 代表工具distutilssetuptoolseasy_install
  • 状态:最初 Python 甚至没有统一的第三方包下载中心。后来有了 PyPI(当时叫 Cheese Shop)。确立了写 setup.py 脚本来打包代码的古典传统。
  • 痛点easy_install 可以下载包,但无法卸载,也没有环境隔离的概念。所有的包都挤在全局操作系统的 site-packages 里,导致不同项目极易发生依赖冲突(Dependency Hell)。

二、 经典标准时代(2008 - 2016):pip + requirements.txt

  • 发起者PyPA (Python Packaging Authority,半官方标准组织)Python 核心团队
  • 代表工具pip(大神 Ian Bicking 始创,后捐给 PyPA)、virtualenv(后被官方吸纳进标准库为 venv)。
  • 状态pip 取代了 easy_install,支持了卸载和精准的版本控制。virtua·lenv 提出了“虚拟环境”的概念,让每个项目拥有独立的 Python 解释器和包目录。这套组合拳至今仍是云服务器和 Docker 部署的最基础标准。
  • 痛点:依赖关系写在单纯的纯文本 requirements.txt 里,它无法区分“开发环境依赖”(如 pytest)和“生产环境依赖”(如 django);且缺乏严格的依赖锁(Lock file)机制,导致往往只锁定了顶层包,底层包更新依然会导致“在我的电脑上能跑,在服务器上跑不了”。

三、 科学计算分支(2012 至今):conda + environment.yml

  • 发起者Anaconda Inc. (商业公司,创始人 Travis Oliphant 也是 NumPy 核心作者) 以及后来的开源咨询公司 QuantStack (开发了极速版 mamba)。
  • 代表工具conda (Anaconda / Miniconda)、mamba
  • 状态:数据科学与 AI 爆发。许多科学包(如 NumPy, TensorFlow)底层深度依赖 C/C++ 或 Fortran。当时用 pip 安装需要本地现场编译源码,无数人被满屏红字报错折磨。conda 另起炉灶,自己建服务器,直接分发预编译好的二进制文件,并能同时跨语言管理 Python 版本和系统级依赖(如 CUDA)。
  • 痛点:体系过于庞大和沉重,拥有自己独立的一套包索引(Conda channel),与标准的纯 pip 生态(PyPI)不完全兼容,混用极易产生深度冲突。

四、 现代化探索时代(2017 - 2021):poetry + pyproject.toml

  • 发起者:受够了官方工具折磨的民间开源大神主导的体验革新。
  • 背景:社区眼馋 Node.js (npm) 和 Rust (cargo) 优秀的工程管理体验,决定废弃可执行的 setup.py,引入静态的统一配置文件 pyproject.toml (PEP 518标准)。
  • 代表工具与演进
    • Pipenv:由 Python 标杆库 requests 的作者 Kenneth Reitz 发起。试图将 pipvirtualenv 结合,引入了锁文件机制。曾被官方短暂推荐,但因依赖解析极慢、后期维护停滞而逐渐失宠。
    • Poetry:由法国开发者 Sébastien Eustace 独立打造。真正意义上的现代 Python 工程管理标杆。支持极度优雅地管理依赖、自动创建虚拟环境、严格锁定依赖版本并支持一键发布,成为目前大多数现代商业和开源项目的标配。
    • (补充) PDM:由中国开发者 Frost Ming 发起,最早且最彻底拥抱 PEP 现代标准的工具,也是这一时期的杰作。

五、 次世代极速流派(2025年以后):uv + pyproject.toml

  • 发起者Astral 公司(创始人 Charlie Marsh,极速代码工具 ruff 的作者)与 Python 社区泰斗 Armin Ronacher(Flask 作者)。主打“用 Rust 重写一切 Python 底层工具”的降维打击。
  • 背景:随着 Python 项目规模越来越大,现有的 Python 包管理器(即使是 Poetry)在解析复杂依赖树时依然显得太慢。社区开始追求极致的性能和真正的“All-in-one(大一统)”。
  • 代表工具
    • uv:目前绝对的性能怪兽与黑马。用 Rust 编写,速度比 pipPoetry 快几十倍甚至上百倍。它现在已经演进为全能管家:可以自动下载 Python 解释器(替代 pyenv)、创建虚拟环境(替代 venv)、极速安装依赖(替代 pip)、运行单文件脚本,并且完全兼容现有的 pip 习惯和 pyproject.toml 标准。
    • Rye:Flask 作者 Armin 发起的实验性大一统工具。在意识到 uv 底层的强大后,Armin 展现了极高的开源精神,主动与 Astral 团队合流,将 Rye 的未来交由 uv 来实现,避免了社区的进一步分裂。
  • 最终状态:未来的 Python 开发,只需安装一个极其小巧的 uv,无需提前安装 Python 环境,用几行极速命令即可搞定一切版本控制、环境隔离与依赖管理。