依附之门:"放弃进入这里的所有希望."
插图: Gustave Doré
Python 的虚拟环境极大地方便了人们的生活. 本指南先介绍虚拟环境的基础知识以及使用方法, 然后再深入介绍虚拟环境背后的工作原理.
注意: 本指南在 macOS Mojave 系统上使用最新版本的 Python 3.7.x.
目录
. 为什么使用虚拟环境?
. 什么是虚拟环境?
. 使用虚拟环境
. 管理环境
. 虚拟环境如何运行?
1. 为什么使用虚拟环境?
虚拟环境为一系列潜在问题提供简单的解决方案, 尤其是在以下几个方面:
. 允许不同的项目使用不同版本的程序包, 从而解决依赖性问题. 例如, 可以将 Project A v2.7 用于 Project X, 并将 Package A v1.3 用于 Project Y.
. 通过捕获需求文件中的所有包依赖项, 使项目自包含且可重现.
. 在没有管理员权限的主机上安装软件包.
. 只需要一个项目, 无需在系统范围内安装软件包, 就能保持全局 site-packages / 目录整洁.
听起来很方便, 不是吗? 开始构建更复杂的项目并与其他人协作时, 虚拟环境的重要性会凸显出来. 很多数据科学家也需要熟悉虚拟环境中与多语言相关的 Conda 环境.
可按照先后次序来使用!
2. 什么是虚拟环境?
到底什么是虚拟环境?
虚拟环境是用于依赖项管理和项目隔离的 Python 工具, 允许 Python 站点包 (第三方库) 安装在本地特定项目的隔离目录中, 而不是全局安装(即作为系统范围内的 Python 的一部分).
这听起来不错, 但到底什么是虚拟环境呢? 虚拟环境只是一个包含三个重要组件的目录:
. 安装了第三方库的 site-packages / 文件夹.
. 系统上安装的 Python 可执行文件的 symlink 符号链接.
. 确保执行 Python 代码的脚本使用在给定虚拟环境中安装的 Python 解释器和站点包.
最后一点在于会发生一些意想不到的错误, 稍后会讲这一点, 但现在先看看在实际中如何实际使用虚拟环境.
但丁《神曲. 地狱篇》第六章 - 维吉尔安抚 Cerberus
插图: Gustave Doré
3. 使用虚拟环境
创造虚拟环境
假设想要为正在处理的项目创建一个名为 test-project / 的虚拟环境, 该项目具有以下目录树:
test-project/
├── data
├── deliver # Final analysis, code, & presentations
├── develop # Notebooks for exploratory analysis
├── src # Scripts & local project modules
└── tests
需要执行 venv 模块, 它是 Python 标准库的一部分.
- % cd test-project/
- % python3 -m venv venv/ # Creates an environment called venv/
注意: 可使用不同的环境名称替换 "venv/".
瞧! 虚拟环境诞生了. 现在项目变成:
test-project/
├── data
├── deliver
├── develop
├── src
├── tests
└── venv # There it is!
提醒: 虚拟环境本身就是一个目录.
唯一要做的事情是通过运行前面提到的脚本来 "激活" 环境.
- % source venv/bin/activate
- (venv) % # Fancy new command prompt
现在我们位于活动的虚拟环境中(由命令提示符指示, 前缀为活动环境的名称).
我们会像往常一样处理项目, 确保项目与系统的其他部分完全隔离. 在虚拟环境中, 我们无法访问系统范围的站点包, 并且无法在虚拟环境之外访问安装包.
完成项目工作时, 可以通过以下代码退出环境:
- (venv) % deactivate
- % # Old familiar command prompt
安装包
默认情况下, 只在新环境中安装 pip 和 setuptools.
- (venv) % pip list # Inside an active environmentPackage Version
- ---------- -------
- pip 19.1.1
- setuptools 40.8.0
如果想要安装第三方库的特定版本, 比如 numpyv1.15.3, 可像往常一样使用 pip.
- (venv) % pip install numpy==1.15.3
- (venv) % pip listPackage Version
- ---------- -------
- numpy 1.15.3
- pip 19.1.1
- setuptools 40.8.0
现在可在脚本或活动的 Python shell 中导入 numpy. 例如, 假设项目包含以下几行脚本 tests / imports-test.py.
- #!/usr/bin/env python3
- import numpy as np
直接从命令行运行这个脚本时, 可得到:
- (venv) % tests/imports-test.py
- (venv) % # Look, Ma, no errors!
成功. 脚本导入 numpy 没有故障.
但丁和 Virgil 穿过 Styx 河 - 但丁《神曲. 地狱篇》第八章
插图: Gustave Doré
4. 管理环境
需求文件
使我们的工作成果可被他人重新使用的最简单方法是在项目的根目录 (顶层目录) 中加入一个需求文件. 为此, 需要运行 pip freeze, 以下列出已安装的第三方软件包及其版本号:
- (venv) % pip freeze
- numpy==1.15.3
并将输出写入文件, 我们称之为 requirements.txt.
(venv) % pip freeze> requirements.txt
更新软件包或安装新软件包时, 都可使用相同的命令重写需求文件.
现在, 任何共享项目的人都可以使用 requirements.txt 文件, 通过复制环境以在系统上运行项目.
复制环境
等等 -- 究竟是怎么做到的?
想象一下, 我们的队友 Sara 从团队的 GitHub 存储库中删除了测试项目. 在她的系统上, 项目的目录树如下所示:
test-project/
├── data
├── deliver
├── develop
├── requirements.txt
├── src
└── tests
注意到有点不寻常的东西了吗? 是的, 没错! 没有 venv / 文件夹.
我们已经将它从团队的 GitHub 存储库中删除, 因为它的存在可能会引起麻烦.
这就是使用 requirements.txt 文件对复制项目代码至关重要的一个原因.
要在机器上运行测试项目, Sara 需要做的就是在项目的根目录中创建一个虚拟环境:
- Sara% cd test-project/
- Sara% python3 -m venv venv/
并使用 pip install -r requirements.txt 将项目的依赖项安装在活动的虚拟环境中.
- Sara% source venv/bin/activate
- (venv) Sara% pip install -r requirements.txt
- Collecting numpy==1.15.3 (from -r i (line 1))
- Installing collected packages: numpy
- Successfully installed numpy-1.15.3
现在, Sara 系统上的项目环境与我们的系统完全相同. 很整洁, 不是吗?
故障排除
可惜事情并不总是按计划进行, 总会遇到一些问题. 也许错误地更新了特定的站点包后发现自己处于 Dependency Hell 的第九级, 无法运行单行项目代码. 也许它没那么糟糕, 可能你会发现自己竟处于第七级.
无论你发现自己处于何种程度, 解决问题并再次看到希望的最简单方法是重新创建项目的虚拟环境.
- % rm -r venv/ # Nukes the old environment
- % python3 -m venv venv/ # Makes a blank new one
- % pip install -r requirements.txt # Re-installs dependencies
大功告成, 多亏了 requirements.txt 文件, 又恢复了正常. 然而另一个原因是始终要在项目中列入需求文件.
但丁与冰中的叛徒对话 -- 但丁《神曲. 地狱篇》第 32 章
插图: Gustave Doré
5. 虚拟环境如何做到这一点?
想了解更多有关虚拟环境的信息吗? 比如, 活动环境如何使用正确的 Python 解释程序并如何找到合适的第三方库?
echo $ PATH
这一切都归结为 PATH 的价值, 它告诉 shell 使用什么 Python 实例以及在哪里寻找网站包. 在基础 shell 中, PATH 看起来或多或少是这样表现的.
- % echo $PATH
- /usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin
调用 Python 解释器或运行. py 脚本时, shell 会按顺序搜索 PATH 中列出的目录, 直到遇到 Python 实例. 要查看 PATH 首先找到的 Python 实例, 请运行 which python3.
- % which python3
- /usr/local/bin/python3 # Your output may differ
通过站点模块 (这是 Python 标准库的一部分) 查找此 Python 实例查找站点包的位置也很容易.
- % python3 # Activates a Python shell
- >>> import site
- >>> site.getsitepackages() # Points to site-packages folder['/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages']
运行脚本 venv / bin / activate 修改 PATH, 以便 shell 在搜索系统的全局二进制文件之前搜索项目的本地二进制文件.
- % cd ~/test-project/
- % source venv/bin/activate
- (ven) % echo $PATH~/test-project/venv/bin:/usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin
现在 shell 知道如何使用项目的本地 Python 实例:
- (venv) % which python3
- ~/test-project/venv/bin/python3
在哪里可以找到项目的本地站点包?
- (venv) % python3
- >>> import site
- >>> site.getsitepackages()['~/test-project/venv/lib/python3.7/site-packages'] # Ka-ching
理智检查
还记得以前的 tests / imports-test.py 脚本吗? 看起来是下面这样:
- #!/usr/bin/env python3
- import numpy as np
我们能够在活动环境中运行此脚本, 不出现任何问题, 是因为环境中的 Python 实例能够访问项目的本地站点包.
如果运行从项目的虚拟环境外部而来的相同脚本会发生什么?
- % tests/imports-test.py # Look, no active environmentTraceback (most recent call last):
- File "tests/imports-test.py", line 3, in
- import numpy as npModuleNotFoundError: No module named 'numpy'
是的, 出现了一个错误, 但我们应该这样做. 如果我们不这样做, 那就意味着我们能够从项目外部访问项目的本地站点包, 从而破坏了拥有虚拟环境的整个目的. 出现错误的事实证明我们的项目与系统的其他部分完全隔离.
环境的目录树
有一件事可以帮助整理所有这些信息, 即清楚地了解环境目录树的外观.
test-project/venv/ # Our environment's root directory
├── bin
│ ├── activate # Scripts to activate
│ ├── activate.csh # our project's
│ ├── activate.fish # virtual environment.
│ ├── easy_install
│ ├── easy_install-3.7
│ ├── pip
│ ├── pip3
│ ├── pip3.7
│ ├── python -> /usr/local/bin/python # Symlinks to system-wide
│ └── python3 -> python3.7 # Python instances.
├── include
├── lib
│ └── python3.7
│ └── site-packages # Stores local site packages
└── pyvenv.cfg
但丁和维吉尔回到了人世间 -- 但丁《神曲. 地狱篇》第 34 章
插图: Gustave Doré
来源: http://www.jianshu.com/p/4ae3d6430dbc