在运行时隔离 Python 的方法有几种。最简单也最显而易见的方法，就是手动修改 PATH
和 PYTHONPATH 环境变量或将 Python 二进制文件移动到其他位置，以改变它发现可用
Python 包的方式，将环境变量修改成保存项目依赖的自定义位置，当然这种方法也最难维
护。幸运的是，有几种工具可以帮助维护虚拟环境，并维护系统中安装包的存储方式。这
些工具主要包括：virtualenv、venv 和 buildout。它们在底层做的事情实际上与我
们手动做的一样。实际的策略取决于具体的工具实现。但一般来说，它们更方便使用，而且还有其他好处。
1．virtualenv
在这个工具列表中，virtualenv 是目前最常用的工具。它名字的含义就是虚拟环境
（virtual environment）。它并不是 Python 标准发行版的一部分，所以需要用 pip 来获取。它
也是值得在系统层面安装的 Python 包之一（在 Linux 系统和基于 Unix 的系统中要用到
sudo）。
安装完成后，利用下面的命令可以创建一个新的虚拟环境：
virtualenv ENV
这里的 ENV 应替换为新环境的名字。这将在当前工作目录路径中创建一个新的 ENV
目录。里面包含以下几个新目录。
• bin/：里面包含新的 Python 可执行文件和其他包提供的脚本/可执行文件。
• lib/和 include/：这些目录包含虚拟环境中新 Python 的支持库文件。新的 Python
包将会安装在 ENV/lib/pythonX.Y/site-packages/中。
创建好新环境后，需要用 Unix 的 source 命令在当前 shell 会话中激活它：
source ENV/bin/activate
这将会影响环境变量，从而改变当前 shell 会话的状态。为了告知用户已经激活了虚拟环
境，shell 提示符会在开头增加(ENV)字符串。下面举个例子，在会话中创建一个新环境并激活：
$ virtualenv example
New python executable in example/bin/python
Installing setuptools, pip, wheel...done.
$ source example/bin/activate
(example)$ deactivate
$
关于 virtualenv 要注意，最重要的是它完全依赖于在文件系统中的存储状态。它不
会提供额外功能来跟踪应该安装哪些包。这些虚拟环境不可移植，不能移动到其他系统或
机器。对每个新的应用部署来说，都需要从头开始创建新的虚拟环境。因此，virtualenv
用户有一个良好实践，就是将所有项目依赖保存到一个 requirements.txt 文件（约定
命名）中，正如下面的代码所示：
# 井号（#）后面的内容是注释。
明确版本号，可重复性高。
graceful==0.1.1
# 如果项目在不同依赖版本中都通过测试，
# 也可以指定相对版本编号。
falcon>=0.3.0,<0.5.0
# 应尽量明确 Python 包的版本，
# 除非始终需要最新版。
pytz
有了这个文件，用 pip 就可以轻松安装所有依赖，因为它可以接受需求文件作为参数：
pip install -r requirements.txt
需要记住，需求文件并不总是理想的解决方案，因为它没有给定依赖的准确列表，而
只给出了需要安装的依赖。因此，如果需求文件并非最新版，无法反映环境的实际状态，
那么整个项目在开发环境中可以正常运行，但在其他环境中却无法启动。当然，pip
freeze 命令可以打印出当前环境所有的 Python 包，但不应该盲目使用这个命令。它会打
印出所有内容，甚至那些仅用于测试而并不用于项目的 Python 包。本书提到的另一款工具
buildout 就解决了这个问题，所以可能是某些开发团队的更佳选择。
2．venv
虚拟环境很快逐步完善，成为了社区中的常用工具。从 Python 3.3 开始，标准库已经
支持创建虚拟环境。其用法与 Virtualenv 几乎相同，虽然命令行选项采用了不同的命名约
定。新的 venv 模块提供了 pyvenv 脚本，可以用于创建新的虚拟环境：
pyvenv ENV
这里的 ENV 应替换为新环境的名字。此外，现在也可以用 Python 代码直接创建新的环境，因为所有功能都包含在内置的 venv 模块中。其他用法和实现细节（例如环境目录
的结构、激活/关闭脚本）与 Virtualenv 几乎完全相同，所以换用这种方法应该很简单，也
不会牵扯太多精力。
对于使用较新版本 Python 的开发人员来说，推荐使用 venv 而不是 Virtualenv。对于
Python 3.3 版，切换到 venv 可能需要付出更多的精力，因为这一版本在新环境中没有默认
安装 setuptools 和 pip，所以用户需要手动安装它们。幸运的是，这一点在 Python 3.4
中已经修改，并且由于 venv 的可定制性，其内容可以被改写。对于细节的解释可参见 Python
文档，但有些用户可能会认为它过于复杂，仍然在这一版本的 Python 中继续使用 Virtualenv。
3．buildout
buildout 是一个强大工具，可与引导启动并部署用 Python 编写的应用。它的一些高级
特性将在本书后面讲到。在很长一段时间内，他还被用作创建 Python 隔离环境的工具。由
于 buildout 需要声明性的配置，每次依赖发生变化都必须修改配置，因此这些环境更容易
复制和管理，无需依赖环境状态。
不幸的是，这一情况已发生变化。从 2.0.0 版开始，buildout 包不再提供与系统 Python
在任何层级的隔离。处理隔离的任务留给其他工具来做，如 virtualenv，所以仍然可以用 buildout
来做隔离，但事情变得有点复杂。buildout 必须要在隔离环境中初始化才能真正隔离。
与之前版本的 buildout 相比，这一版本有一个主要缺点，就是它要依赖其他隔离方法。
开发这些代码的开发人员不再确定对依赖的描述是否完整，因为有些 Python 包可以绕过声
明性配置来安装。当然，这个问题可以通过适当的测试和发布过程来解决，但却使整个工
作流程更加复杂。
总而言之，buildout 不再是提供环境隔离的解决方案，但其声明性配置可以提高虚拟环
境的可维护性和可重复性。
