virtualenv系列 · 导致Python多版本依赖困境的根源

Posted 2022-12-16 bluishglc

多版本依赖管理一直是Python的一个痛点，广受诟病，尽管这么多年下来，Python早已提出了以“虚拟环境”为代表的多种成熟解决方案，但依然难掩Python在设计之出在包管理系统上犯下的理念性错误。

Python的包管理系统与Yum非常类似，可能在设计之出就是借鉴了Yum等Linux系统包管理工具的设计理念。这导致了Python包管理系统存在一个天生的缺陷：同一软件包只允许存在一个版本！这给Python后来带来了麻烦。

操作系统的软件环境通常是比较稳定和单一的，特别是服务器。对于操作系统而言，一个软件包只安装一个版本是很常见的，在操作系统层面上，需要安装和使用同一软件包的多个版本的情况并不常见，一般在安装或升级了高版本后，利用高版本对低版本的向下兼容，都可以很好的化解，这也是为什么这么年Yum一类的包管理工具能一直在Linux系统上稳稳地占据着位置的原因。

但是，使用编程语言开发项目时对依赖包的管理与操作系统的包依赖管理是有很大差异的，最大的区别在于：在一个本地开发环境中，我们可以创建任意多的Python工程，它们对于依赖的软件包/类库都有不同的版本需求，由于Python的包管理系统对于同一软件包只允许存在一个版本，这就导致单一的Python环境（包管理器）根本不能应对多个不同的Python项目，导致所谓的：“多版本依赖困境”。

实际上，对于那些从其他编程语言转到Python的程序员来说，很容易在一开始接触Python时就意识到了这个问题，并且也很容易能看出导致这一问题的根源是什么。一个有力的参照就是Java中的Maven，Maven只在操作系统上构建一个中心化的Repo（存放依赖包的目录），所有的Java项目都通过Maven的中心仓库找到自已依赖的Jar包，Maven可以轻松应对不同Java项目对同一Jar包不同版本的依赖需求，而做法也非常简单，就是每一个版本单独存放一份，允许多版本共存¹，另人遗憾的是，Python的包管理系统没有这样设计（应该是当时没有成熟的参考，实际上Maven的处理方式可以算是编程语言在包依赖管理上的“设计模式”了，设计理念是通用的），所以才有了后来Python自己的解决方案：虚拟环境。

---

1. 实际上，Maven通过POM中groupId -> artifactId -> version构建了一套严格的Jar包坐标体系，既确保了Jar包在版本级别上的唯一性又能快速定位Jar包位置。 ↩︎