Skip to content

Python 虚拟环境管理方案比较

背景

Python 虚拟环境管理是工程开发中非常重要的一个环节，在这个领域中，各路豪杰齐聚一堂 共襄盛举每个人都在造轮子结果干出一堆虚拟环境管理方案。这些方案包括：

  • virtualenv：老当益壮的虚拟环境管理方案
  • venv：官方推荐，安装 python 时自带
  • anaconda：与其说是Python虚拟环境管理方案，不如说是科学计算平台，不仅仅能管理 python 虚拟环境。功能强大，体积厚重。
  • pipenv：作者没有用过，只是在网上看到了，所以放在这里。 😆

然后在这些玩意之上，又有不同的包装、改进：

  • virtualenv 系列：virtualenvwrapper、pew 等，相见官方友情链接
  • conda 系列：miniconda。对anaconda进行了大规模的瘦身，安装时仅安装一个 python 核心，其他各种库在需要时再下载。

这么多虚拟环境管理方案难免让初学者望而生畏，不知所云。种种管理方案之间到底有什么区别？程序员应该如何选择最合适自己的管理方案呢？本文与大家分享一些自己的经验。

比较

时效性须知

软件的更新迭代非常迅速，本文写于 2023 年，所有比较基于这一特定时间下各个管理方案的最新版本进行，读者需根据阅读时间自行判断后续内容是否过时。

上面几种虚拟环境管理方案中我使用过三款：virtualenv、venv、miniconda。上述各种改进、包装也没能超出这三款的能力范围，所以我将比较这三款方案。后文中 conda 代指 miniconda，因为 anaconda 安装包中包含太多软件包，所以一般建议使用 miniconda。

三款管理方案的比较汇总如下：

方案 安装 独立性 支持 py2 支持 py3 多 py 版本管理 非pypi包管理
virtualenv via pip ❌ 依赖已安装py版本 ❌
venv builtin ❌ ❌ >= 3.3 ❌ ❌
conda via script

独立性 & 安装

独立性指在安装这个管理方案时，是否依赖系统中已经安装的 python 环境。三个方案中只有 conda 保证完全独立；virtualenv 依赖已有的 python 环境的 pip 工具安装，管理多 python 版本的前提是系统已经安装这些版本，不具备独立性；venv 是 python 的一个内置模块，自然没有独立性的概念。

conda 在安装环节也比较特殊，安装时需要从 miniconda 官方网站下载一个安装脚本，使用这个脚本进行安装。这个脚本会安装如下模块：

  • conda 核心
  • 一个独立的 python 解释器和对应的 pip
  • zlib 等其他小工具

后续对使用 conda 的所有操作都将基于这个独立的 python 解释器进行，不会影响到用户自行安装的其他 python。

走向另一个极端的是 venv，作为 python 的官方内置模块，它没有任何独立性可言，完全依附于某个特定版本的 python 运行。

不同场景中对独立性有不同的需求，例如：

  • 如果系统预装了python，且部分系统功能依赖这个 python，如 ubuntu 系统，建议使用 conda，保持系统预装 python 的纯净，避免各种 edge-case 弄崩 python 环境导致系统功能异常。

  • 如果希望用户开箱即用虚拟环境管理功能，建议使用 venv。官方预装，省去很多麻烦。

Python 版本支持 & 多版本管理

概念辨析：

  • 版本支持：指管理方案能够管理某个版本的 python
  • 多版本管理：指管理方案能管理多个不同版本的 python 虚拟环境

具体地说：

  • virtualenv 安装在 py3 上，具有管理 py2、py3 能力，但创建特定版本虚拟环境的前提是系统中已经安装了这个版本的 python。例如，在 ubuntu 中，可以同时在系统中安装 python 2.7、python 2.9、python 3.6、python 3.11。假设 virtualenv 安装在 python 3.6 的第三方库中，那么这个 virtualenv 可以创建上述 python 版本号的虚拟环境。但不能创建 python 3.8 的虚拟环境，因为系统中并未安装。

  • venv 不支持 py2 也不具备管理多个 python 版本环境的能力。但因为一个系统可以安装多个版本的 python，所以用不同版本 python 中的 venv 模块就能创建不同 python 版本的虚拟环境。虽然不能原生支持多版本管理，但绕几个弯也能做到。

  • conda 支持能力最强。在创建特定版本 python 环境时会自动从 conda 仓库下载指定版本 python 和 pip 并安装在虚拟环境中，功能最强大。同时使用也最方便，不需要手动安装各个版本 python，免去很多繁琐的安装步骤。

非pypi包管理

该项已经超出了“python 虚拟环境”管理的范畴，所以只有 conda 作为一个“科学计算管理平台”能够完整支持这个功能。

conda 能够管理那些不属于 pypi 维护的软件包，例如 AI 领域必备的 cudatoolkit。要想在一台电脑中同时管理多个 CUDA 版本是非常繁琐并且容易出错的操作，你需要花费大量的时间在网上搜索资料、阅读 NVIDIA 官方冗长的 CUDA 安装手册，并手动管理多个 GCC 版本。这些 overhead 会严重拖累项目开发，自然希望避免手动管理 CUDA 环境。

在我有限的认知中，只有 conda 能够做到自动管理 cudatoolkit。例如：

conda create -n py3-cuda11 python=3.8 cudatoolkit=11

将会创建一个名为 py3-cuda11 的python虚拟环境，且使用 3.8 版本解释器和CUDA 11的运行库。

注：cudatoolkit 是平常互联网语境中安装 cuda 中的一个子集，但只要系统以及安装 nvidia driver，那么仅 cudatoolkit 足以支持运行 tensorflow、pytorch。cudatoolkit 和所谓“安装 cuda” 更细致的关系已经超出本文的讨论范围，感兴趣的读者可以参考 nvidia 给出的官方解释。

总结

上述比较以及涵盖大部分 Python 使用场景，在阅读上述比较之后读者不难选择出最适合自己的管理方案。

下面是一些个人建议：

  • 如无特别要求，首选 miniconda。功能最强，独立安装，不影响系统。是最令人满意的python虚拟环境管理方案。

  • 要管理多个 python 2 版本的虚拟环境，选择 miniconda。虽然现在已经是2023年，大部分项目已经只支持 python 3了，但确实存在许多祖宗之法不可动的上古代码。miniconda 仍然支持安装各个 python 2 版本的虚拟环境。

  • 要求开箱即用，选择 venv。官方推荐，开箱即用，功能简单恰到好处。

  • 无能为力，或是项目特殊要求，最后才考虑 virtualenv。虽然这个管理方案提出时间非常早，为python虚拟环境管理方案的演进做出很大的贡献，但确实有些更不上时代了。论功能，没有 conda 强大，论简洁，没有 venv 方便。或许 virtualenv 已经丧失它的生态位了。

推荐阅读

💡 好奇如何优雅使用 miniconda？来看看这个吧：conda-推荐配置

Comments