Question

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

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之前，我们仍然有一些问题要解决。