Python 包管理工具小结 - 文章教程

Python 包管理工具小结

发布于 2021-03-12 字数 10428 浏览 1062 评论 0

作为一名接触 Python 有一段时间的初学者,越来越体会到 Python 的方便之处,它使人能更 多的关注业务本身的逻辑,而不用太纠结语言层面的技巧与细节。然而,随着服务的规模 变得越来越大,如何方便快速地制作与发布一个 Python 软件包则越来越成为一个让人头疼 地问题,特别是像 Openstack 这种相对复杂、各种依赖也很多的 Python 项目,到目前也没有 发现特别完美的解决方案。这里将尝试对Python的包管理工具做一个小结,为将来更好的 解决这个问题提供思路。

setuptools

setuptools1 是Python提供的最基本的包管理工具,后面提到的其他更高层次的Python 包管理工具都是在它的基础上实现的。曾经Python还有其他各种各样类似功能的包管理工 具,比如distribute、distutils等等,对有选择困难症的同学非常不友好,不过目前绝大 多数Python项目都开始统一使用setuptools,其他工具已经被慢慢合并/遗弃了。

setuptools的常见使用方式是在Python项目中新建一个setup.py:

from setuptools import setup, find_packages
setup(
    name = "HelloWorld",
    version = "0.1",
    packages = find_packages("helloworld"),
)

在这个文件中通过setuptools提供的各种关键字描述项目的元信息,包括名字、版本、 文件等等。写好后就可以通过python setup.py [command]执行setuptools提供的各种子 命令,比如编译、安装、测试、制作各种格式的软件安装包等等。

当你拿到一份Python项目的源代码,如果它已经写好了setup.py,你就可以方便的通过 setuptools将它安装到系统:

$ python setup.py install

目前,使用setuptools制作的软件安装包常见格式有:

source distro

$ python setup.py sdist

binary distro: egg

$ python setup.py bdist_egg

binary distro: wheel

$ python setup.py bdist_wheel

以openstack/nova为例,对应的三种格式软件安装包分别为:

nova-12.0.0.0b2.dev251.tar.gz
nova-12.0.0.0b2.dev251-py2.7.egg
nova-12.0.0.0b2.dev251-py2.py3-none-any.whl

sdist和wheel格式的安装包都可以使用最常见的pip命令安装,egg还只能通过 比较老得easy_install命令安装。

$ pip install nova-12.0.0.0b2.dev251.tar.gz
$ easy_install nova-12.0.0.0b2.dev251-py2.7.egg
$ pip install nova-12.0.0.0b2.dev251-py2.py3-none-any.whl

pbr

从上面的例子里可以看到,setup.py本质上还是一个Python脚本,有诸多语法的限制。 当Python项目比较庞大和复杂时,setup.py就会变的非常难写与维护。 在Openstack中,新建了一个pbr2 项目来处理这个问题。通过使用pbr项目提供的维护与 setup.py对应的setup.cfg文本配置文件来自动生成setup.py从而解决这个问题。

比如上面的例子,切换到pbr就会变成这样:

setup.py

from setuptools import setup

setup(
    setup_requires=['pbr'],
    pbr=True,
)

setup.cfg

[metadata]
name = HelloWorld
version = 0.1

[files]
packages =
    helloworld

当然,实际工程中,setup.cfg文件的内容会比这个例子复杂很多。

pip

setuptools解决了Python软件包的制作问题,那如何分发它们呢?Python本身提供了PyPI 基础设施与相应的pip3 命令行工具来做这件事。

你可以将生成好的软件包通过

$ python setup.py upload

通过网络上传到PyPI。 上传成功后,其他人就可以直接通过pip命令安装你上传的软件包:

$ pip install ${package_name}

virtualenv

提到了pip,就不得不提一下virtualenv4 ,这两个工具经常是在一起搭配使用的。

virtualenv的功能有点像Linux系统下的chroot命令,运行

$ virtualenv .venv

后,他会将最小安装一个Python运行环境到当前目录的.venv文件夹,内容包括.venv/bin 下的python、pip命令,.venv/lib下的python库目录等等。当你使用

$ . .venv/bin/activate

激活刚刚创建出来的这个virtualenv环境后,你执行的python相关的二进制命令其实都是 .venv/bin目录下(而不是系统路径下的),安装/引用的python库也都是在.venv/lib目录 下的。

这样子,使用virtualenv后可以让每个Python项目使用独立的Python运行环境,不会产生 几个项目间依赖冲突、污染操作系统Python库的问题。

wheel

wheel5 是众多 Python 软件安装包格式的一种,这里专门要把它单独拿出来说是因为它的 优点和好处确实很多,是Python官方推荐的新一代Python项目发布格式,个人也非常希望 目前所有PyPI上项目都能尽快提供wheel格式的安装包。新版本的pip已经可以直接从PyPI 上下载安装wheel格式的安装包了。

和老的 egg6 格式相比,wheel 能让人直观感受到的先进之处:

  • 不包含.pyc文件(预编译的.pyc文件偶尔会导致各种奇怪的问题,我们更希望他能在 每次安装时在本地生成更新),当项目是纯Python项目时wheel和source distro基本 没有什么区别。
  • 官方支持,pip命令可以直接安装wheel,但是不能处理egg。
  • 更丰富的软件包元信息,甚至包中的每个文件都有版本记录。
  • 更细致的包命名规则

和egg格式一样,wheel拥有的优点:

  • 单安装文件。你是希望从源码文件夹下执行一系列命令编译安装一个Python项目,还是 直接通过一个文件安装呢?
  • 依赖处理。安装程序会帮你自动安装相关依赖的Python库。
  • 二进制发布格式。当项目包含需要编译生成的extension时,可以将编译好的 .so/.dylib/.dll等动态链接库直接一并打包,实现“一次编译,到处运行”(在相同的 平台上)的效果,而不是每次都在终端重新编译生成。这点在大规模服务器上批量部署 Python程序项目非常重要。可惜的是,目前wheel仅在windows和mac os平台支持这个特 性,Linux平台由于各种原因还不支持,希望PyPA能尽快解决吧。

这里有一份官方文档详细比较了wheel和egg: 7

Linux distros

上面总结了Python打包社区PyPA(Python Packaging Authority)本身提供的各种工具, 但是在各个Linux发行版中,出于和系统集成(比如各种配置文件、脚本的管理)、加强 包的管理(PyPI上的软件包都是开发者自行自由上传的)等等原因,很多Linux发行版通常 也会制作维护各自平台上专有的Python项目安装包,比如Debian系的.deb格式安装包 等等。

由于各个Linux发行版的管理风格、系统路径、甚至默认的Python版本等等都大相径庭, 所以各种安装包的规格、内容也差别很大。

常见的Linux发行版里,Debian系的.deb格式和Redhat系的.rpm格式安装包属于比较严格和 保守的一派。它们通常会做严格的版本、依赖控制;维护项目相关的服务配置文件、 SysVinit/systemd、syslog、logrotate脚本等等;安装包会包含任何需要编译的二进制 文件(如.pyc文件、各种需要编译的c extension等),不需要在安装时进行本地编译; 使用Python2作为Python的默认版本,甚至在某些较老的Debian、CentOS的发行版中, 还在使用Python2.6/2.3。

而像ArchLinux这样比较激进的Linux发行版,安装包的管理就非常奔放。安装包通常只是 帮你指定一下依赖、任何软件和库都用最新版本(非常令人讨厌的,Python也默认使用 Python3)、Python项目的PKGBUILD里package()通常就一行 “python2 setup.py install …”。

总结

上面基本把最近自己接触到的和Python相关的包管理工具介绍了一遍,而在实际操作中去 在服务器上批量发布部署Python项目,利用上面提到的这些工具,能想到的通常有下面 几种方式。

每次到这个时候,真的是非常羡慕Java/Go这些不用纠结这种问题的编程语言。

直接源码安装

适合在自己的开发调试机器上瞎搞的时候使用。

由于Python/pip本身的包管理功能比较弱,直接在服务器上用这种方法会给服务器的系统 安装一系列不可控制的Python依赖,并且可能破坏其他Python程序的依赖,导致其他 Python程序无法正常运行。装的时候方便,当你碰到问题想清理的时候可就蛋疼了,相信 维护服务器的SA也不太可能会让你这样做的。

virtualenv+源码直接安装

比较靠谱的办法,但是只适合单机部署。当服务器数量众多,如何实现批量部署发布就是 个困难的问题了。

virtualenv+源码打包发布

在virtualenv环境里安装好所有的Python文件,把整个virtualenv目录打包成一个单独的 tar包。发布时直接将这个tar包拷贝到目标服务器上解压安装。

目前一些知名的Openstack厂商,如Rackspace,就是通过这种方式在服务器上部署Python 项目的。

然而,这样做的缺点是,还需要做很多额外的工作去维护服务的配置文件、脚本、系统上 非Python相关的软件依赖(如kvm、libvirt、openvswitch)等等。

类似方法还有自建私有PyPI源,提前将Python项目打包上传到自建的PyPI源里。然后在 服务器上的virtualenv环境里通过自建的PyPI源安装。

使用Linux发行版本身的安装包

比如,Debian系的.deb安装包、Redhat系的.rpm安装包。它们能比较好的维护各种服务 配置文件、脚本,以及像kvm这样的非Python相关的依赖,我们目前也在使用这种方式。

然而,它也有很多问题,以我比较熟悉的Debian发行版为例:

  • 所有Python项目共用一套Python依赖。当有的Python项目想升级某个第三方库时,会 因为破坏其他Python项目的依赖版本而无法实现。
  • 官方提供的软件版本比较旧。对于一个追求稳定的Linux发行版,这么做本身并无可厚 非,但是有时候当你就是想用新一点版本时,就会感觉非常无奈,基本都要自己动手制 作安装包。而且由于依赖的关系,可能你为了给一个软件制作新版本的安装包,需要再 为其他10个依赖的项目制作新版本的安装包,然后又要为这10个依赖的项目再制作30个 依赖的依赖的新版本安装包。。。
  • 学习成本比较高。Debian的安装包制作方法,除了官方十年前写的几份文档外,网上 其他能找到的资料很少,学起来比较费力。Debian作为一个装机量较大的Linux发行版都 是这样,相信其他发行版也是类似的情况。

virtualenv+源码+Linux发行版安装包打包发布

在virtualenv环境里安装好所有的Python文件,然后将整个virtualenv目录打包到单独的 一个Linux发行版的安装包内,同时在这个安装包内设置好相关的配置文件、脚本、系统 依赖。

理论上这种方法综合了上面两种方式的优点,目前正在调研中,然而相信实践过程中肯定 会踩到不少坑。

spotify公布了他们在Debian下使用这种方式解决Python项目发布部署问题的工具 dh-virtualenv8 ,感兴趣的同学可以参考一下。

References

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。

扫码加入群聊

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

目前还没有任何评论,快来抢沙发吧!

关于作者

JSmiles

生命进入颠沛而奔忙的本质状态,并将以不断告别和相遇的陈旧方式继续下去。

2583 文章
29 评论
84935 人气
更多

推荐作者

清风夜微凉

文章 1 评论 0

为你鎻心

文章 2 评论 0

xxhui

文章 0 评论 0

1PKOH46yx8j0x

文章 0 评论 0

Arthur

文章 0 评论 0