卷1：第14篇 Python打包工具.pdfVIP

卷1 ：第14章 Python打包⼯具 作者：Tarek Ziadé ，翻译：张吉 原⽂：http://www .aosabook .org/en/packaging .html 14.1 简介 对于如何安装软件，⽬前有两种思想流派。第⼀种是 软件应该⾃给⾃⾜，不依赖于 其它任何部件，这点在Windows和Mac OS X系统中很流⾏。这种⽅式简化了软件的管 理：每个软件都有⾃⼰独⽴的“领域 ，安装和卸载它们不会对操作系统产⽣影响。如 果软件依赖⼀项不常见的类库，那么这个类库⼀定是包含在软件安装包之中的。 第⼆种流派，主要在类Linux的操作系统中盛⾏，即软件应该是由⼀个个独⽴的、⼩ 型的软件包组成的。类库被包含在软件包中，包与包之间可以有依赖关系。安装软件 时需要查找和安装它所依赖的其他特定版本的软件包。这些依赖包通常是从⼀个包含 所有软件包的中央仓库中获取的。这种理念也催⽣了Linux发⾏版中那些复杂的依赖 管理⼯具，如dpkg和RPM。它们会跟踪软件包的依赖关系，并防⽌两个软件使⽤了版 本相冲突的第三⽅包。 以上两种流派各有优劣。⾼度模块化的系统可以使得更新和替换某个软件包变的⾮常 ⽅便，因为每个类库都只有⼀份，所有依赖于它的应⽤程序都能因此受益。⽐如，修 复某个类库的安全漏洞可以⽴刻应⽤到所有程序中，⽽如果应⽤程序使⽤了⾃带的类 库，那安全更新就很难应⽤进去了，特别是在类库版本不⼀致的情况下更难处理。 不过这种“模块化 也被⼀些开发者视为缺点，因为他们⽆法控制应⽤程序的依赖关 系。他们希望提供⼀个独⽴和稳定的软件运⾏环境，这样就不会在系统升级后遭遇各 种依赖⽅⾯的问题。 在安装程序中包含所有依赖包还有⼀个优点：便于跨平台。有些项⽬在这点上做到了 极致，它们将所有和操作系统的交互都封装了起来，在⼀个独⽴的⽬录中运⾏，甚⾄ 包括⽇志⽂件的记录位置。 Python的打包系统使⽤的是第⼆种设计思想，并尽可能地⽅便开发者、管理员、⽤户 对软件的管理。不幸的是，这种⽅式导致了种种问题：错综复杂的版本结构、混乱的 数据⽂件、难以重新打包等等。三年前，我和其他⼀些Python开发者决定研究解决这 个问题，我们⾃称为“打包别动队 ，本⽂就是讲述我们在这个问题上做出的努⼒和取 得的成果。 术语 在Python 中， 包 表⽰⼀个包含Python⽂件的⽬录。Python⽂件被称为 模块 ，这样⼀ 来，使⽤“包 这个单词就显得有些模糊了，因为它常常⽤来表⽰某个项⽬的 发⾏版 本 。 Python开发者有时也对此表⽰不能理解。为了更清晰地进⾏表述，我们⽤“Python包 （package ） 来表⽰⼀个包含Python⽂件的⽬录，⽤“发⾏版本 （release ） 来表⽰某个 项⽬的特定版本，⽤“发布包 （distribution ） 来表⽰某个发⾏版本的源码或⼆进制⽂ 件，通常是Tar包或Zip⽂件的形式。 14.2 Python开发者的困境 ⼤多数Python开发者希望⾃⼰的程序能够在任何环境中运⾏。他们还希望⾃⼰的软件 既能使⽤标准的Python类库，又能使⽤依赖于特定系统类型的类库。但除⾮开发者使 ⽤现有的各种打包⼯具⽣成不同的软件包，否则他们打出的软件安装包就必须在⼀个 安装有Python环境的系统中运⾏。这样的软件包还希望做到以下⼏点： 其他⼈可以针对不同的⽬标系统对这个软件重新打包； 软件所依赖的包也能够针对不同的⽬标系统进⾏重新打包； 系统依赖项能够被清晰地描述出来。 要做到以上⼏点往往是不可能的。举例来 ，Plone这⼀功能全⾯的CMS系统，使⽤ 了上百个纯Python语⾔编写的类库，⽽这些类库并不⼀定在所有的打包系统中提供。 这就意味着Plone必须将它所依赖的软件包都集成到⾃⼰的安装包中。要做到这⼀点， 他们选择使⽤zc.buildout这⼀⼯具，它能够将所有的依赖包都收集起来，⽣成⼀ 个完整的应⽤程序⽂件，在独⽴的⽬录中运⾏。它事实上是⼀个⼆进制的软件包，因 为所有C语⾔代码都已经编译好了。 这对开发者来 是福⾳：他们只需要描述好依赖关系，然后借助zc.buildout来发 布⾃⼰的程序即可。但正如上⽂所⾔，这种发布⽅式在系统层⾯构筑了⼀层屏障，这 让⼤多数Linux系统管理员⾮常恼⽕。Windows管理员不会在乎这些，但CentOS和 Debian管理员则会，因为按照他们的管理原则，系统中的所有⽂件都应该被注册和归 类到现有的管理⼯具中。 这些管理员会想要将你的软件按照他们⾃⼰的标准重新打包。问题在