python在工程管理中的应用-Python 工程管理及 virtualenv 的迁移

最新推荐文章于 2021-08-26 22:30:54 发布

weixin_39738115

最新推荐文章于 2021-08-26 22:30:54 发布

阅读量218

点赞数 1

virtualenv 是管理 python 工程的利器，它可以很好的帮你维护项目中的依赖，使用 virtualenv，还能保持 global 库的干净、不会被不同项目中的第三方库所污染。

virtualenv 的默认功能简单好用，可一旦涉及到多人协作，或部署到不同的环境中时，错误的使用 virtualenv 会给你带来一些麻烦，从而你需要花很多时间在解决这些问题上。本文的目的就是总结过去使用 virtualenv 的经验，希望能帮你找到一种正确的打开方式。

首先，创建一个空的 virtualenv 时，你的目录中会包含以下文件和目录

drwxr-xr-x 7 fengyajie staff 224B Mar 21 22:49 .

drwxr-xr-x 8 fengyajie staff 256B Mar 21 20:28 ..

lrwxr-xr-x 1 fengyajie staff 83B Mar 21 22:49 .Python -> /usr/local/Cellar/...

drwxr-xr-x 16 fengyajie staff 512B Mar 21 22:49 bin

drwxr-xr-x 3 fengyajie staff 96B Mar 21 22:49 include

drwxr-xr-x 3 fengyajie staff 96B Mar 21 22:49 lib

-rw-r--r-- 1 fengyajie staff 61B Mar 21 22:49 pip-selfcheck.json

接着当你执行 source bin/activate 后，你安装的依赖都会在 lib 目录下，这一点很诱人，会让你觉得一切尽在掌握，因为该应用程序所需要的一切库文件全在这个 app 的根目录下，所以当这个应用需要部署时，为了避免产生 ImportError: No module named xxx 错误，你会很容易的想到将本地这个 app 目录打包，然后放到远程服务器或容器中去执行。

当你这么做时，你会发现虽然在远程是可以执行 source bin/activate 命令以进入 virtualenv ，但此时你引用的 python 可执行文件却并不是 ${app}/bin/pyhton，而是 global 环境中的那个 /usr/bin/python，所以 ${app}/lib 下的所有依赖包路径仍然是没有被包含进 sys.path 的。

这时，你才发现自己的假设是错误的，并开始怀疑自己使用 virtualenv 的方式存在问题，于是便 google 各种解决方案，但项目已处于部署阶段，时间紧迫，你很可能找不到最优的办法，只能退而求其次，寻求次优解，毕竟依赖包都在嘛，改下 sys.path 不就好了嘛？确实很容易想到这种方法，但又不想手动改，那就写个程序改吧，也不难：

# set_sys_path.py

def set_sys_path():

import sys

for path in sys.path:

if os.path.split(path)[1] == "site-packages":

home = os.path.abspath(os.path.dirname(__file__))

pypath = os.path.join(home, "lib/python2.7")

pypath_sitepackage = os.path.join(home, "lib/python2.7/site-packages")

pth = os.path.join(path, "pth.pth")

with open(pth, "w") as f:

f.write("%s " % pypath)

f.write("%s " % pypath_sitepackage)

if __name__ == "__main__":

set_sys_path()

上面的程序很简单，它将 ${app}/lib/python2.7 和 ${app}/python2.7/site-packages 两个依赖路径写到 pth.pth 文件中，并将该文件 mv 到 global 的 site-packages 目录下，这样当你启动 global 的 python 时，会自动将 pth.pth 里的路径添加到 sys.path 下，这样只需要在启动你的 app 之前，执行该脚本即可，如下：

$ python set_sys_path.py

$ python main.py

问题暂时解决了，这次你的 app 也顺利发布了；但还没结束，我们希望在测试机集群上把 app 的自动化测试做起来，在做自动化测试时，系统会随机给你分配一台机器资源，当测试完成后，资源会被回收。你心想，这仍然很简单嘛，本地测试已经覆盖得很全了，只要自动化系统利用 git 把代码拉下来，先执行 set_sys_path.py 设置 sys.path，再执行 python test.py（测试入口）就可以了。

可这时又出现问题了，自动化测试在执行 set_sys_path.py 时，报 Permission denied 错误，原因是测试机为了保持环境不被污染，不允许你将 pth.pth 复制到 global 的 site-packages 下。

遇到这个问题怎么办？其实也很容易解决：我们都知道 python 中有个环境变量 PYTHONPATH 可以用来设置 sys.path，既然没有写文件的权限，那定义环境变量总该可以吧：

$ export PYTHONPATH=$PYTHONPATH:${app}/lib/python2.7:${app}/lib/python2.7/site-packages

$ python main.py

果然可行，你再一次「顺利」的完成了需求。

经历过多次折腾后，我们发现这种使用 virtualenv 和修改 sys.path 的方法不算很好，还容易出错。于是开始思考最初的那个问题，virtualenv 该怎么迁移？有没有更好的办法？答案肯定是有的，在此之前，我们先仔细观察 virtualenv 产生的文件，会发现其中有 28 个软连接，它们的源文件均在 global 库中，如下所示

$ find . -type l

./.Python

./bin/python

./bin/python2

./include/python2.7

./lib/python2.7/lib-dynload

./lib/python2.7/encodings

...

所以，当你把整个 virtualenv 打包，放到另一个环境中运行时，肯定是会失败的，因为软连接失效了，于是，再一次证实这种把整个 virtualenv 打包的方法，实际上是错误的，virtualenv 就只是一个 local 方案，而不是让你可以「处处运行」的工具。

但 virtualenv 的隔离功能，可以让你只关注项目范围内的依赖包，所以我们可以利用 pip freeze 命令，将项目内的依赖保存到一个叫 requirements.txt 的文件中，这样在任何其他环境，我们只要根据 requirements.txt 文件来安装项目所需的依赖包，即可将本地的运行环境克隆出来，而且这种克隆出来的环境更纯粹，不会受到源环境或 global 库的影响，没有不确定性。下面我们用一个例子来具体说明下：

假设 Bob 和 Alice 同在一个团队，他们决定使用 python 来开发新项目，一开始，Bob 在 github 上创建了一个新 repo，并在本地初始化它：

# 从 github clone 项目

$ git clone https://github.com/your_group/your_repo.git

$ cd your_repo

# 创建并进入 virtualenv

$ virtualenv .

$ source bin/activate

# 修改 .gitignore，过滤掉 virtualenv 产出的文件

$ cat .gitignore

*.py[cod]

__pycache__/

.Python

bin/

include/

lib/

pip-selfcheck.json

# 在本地安装基本依赖，例如 Flask、gevent、gunicorn 等

$ pip install Flask gevent gunicorn -i https://pypi.mirrors.ustc.edu.cn/simple/

# 将本地依赖写入 requirements.txt

$ pip freeze > requirements.txt

# 将变更提交到 github

$ git add .

$ git commit -m "init project"

$ git push origin master

# 继续开发

# ...

Bob 完成了初始化，实际上他只提交了 .gitignore 和 requirements.txt 两个文件到 git 中，之后 Alice 也可以加入进来了：