4.6 Nick Coghlan访谈

Nick是Red Hat公司的Python核心开发人员。他已经写过几个PEP提案,包括PEP 436(http://www.python.org/dev/peps/pep-0426/)(Metadata for Python Software Packages 2.0),他是这个提案的BDFL2代表。

阅读 ‧ 电子书库

广告:个人专属 VPN,独立 IP,流量大,速度快,连接稳定,多机房切换,每月最低仅 10 美元

Python的打包方案(distutils、setuptools、distutils2、distlib、bento、pbr等)的数量真是令人印象深刻。根据你的观点,是什么(可能的历史性)原因造成这样的分裂和分化?

简单地回答就是软件的发布、分发和集成是很复杂的问题,所以有很大的空间共存多个针对不同使用场景的解决方案。详细的答案请参考Python打包用户指南([https://python- packaging-user-guide.readthedocs.org/en/latest/future.html#how-we-got-here](https://python- packaging-user-guide.readthedocs.org/en/latest/future.html#how-we-got-here))。我在最近关于这个问题的表述中已经指出,问题的主要原因之一是年代,上述这些工具大多产生于软件分发技术的不同时代。

setuptools 如今已经是Python分发工具的事实标准。你觉得有什么问题是用户在使用(或者不用)它时需要注意的吗?

setuptools作为构建系统是相当不错的,尤其是对纯Python项目或者只有简单的C扩展的项目。它还为插件注册和良好的跨平台脚本生成提供了强大的系统支撑。

尽管如此,pkg_resources中的多版本支持要想用好仍然显得有点儿刁钻古怪。除非有非常充分的理由要在同一个环境中包含互相冲突的版本,否则这样只使用virtualenv或zc.buildout会更容易。

PEP 426定义了Python包的一种新格式,但它仍然非常新而且尚未批准。它的进展还顺利吗?最开始的动机是什么?你觉得它能解决当前的问题吗?

PEP 426最早源于Wheel格式定义的一部分,但是Daniel Holth最终意识到Wheel能够同已有的setuptools定义的格式一起工作。因此PEP 426是已有的setuptools元数据和一些来自distutils2以及其他打包系统(如RPM和npm)的想法的融合,并且解决了现有工具中遇到的一些问题(如清楚地隔离不同类型的依赖)。

如果PEP 426被接受的话,你希望看到出现什么样的工具来充分利用PEP 426?

主要的好处是PyPI将能够通过REST API提供完整的元数据访问,并且(希望能)具有根据上传的元数据自动生成策略兼容的分发包的能力。

Wheel格式非常新,还没有被广泛使用,但看上去很有前途。是什么原因造成它还不是标准库的一部分呢?是否已经有计划包含它?

事实证明,打包标准并不太适合放到标准库里:它的演进太慢,并且对后面版本的扩展并不能用在Python的早期版本中。所以,在今年早些时候的Python语言峰会上,我们调整了PEP流程,以便用distutils-sig管理打包与相关PEP的完整审批流程。python-dev将只参与那些直接涉及修改CPyhon的提案(如pip引导)。

根据你的设想,未来怎样的发展会推动开发人员去构建和分发Wheel格式的包?

pip正在接受其成为Egg格式的备选方案,允许构建的本地缓存以便快速创建虚拟环境,并且PyPI允许上传针对Windows和Mac OS X平台的Wheel归档文件。在它适用于在Linux之前,我们仍然有一些问题要解决。