setuptools vs. distutils：为什么distutils仍然是一个东西？

Question

Python就可以用于打包和描述项目的工具，一个令人困惑的历史：这些包括distutils标准库中， distribute ， distutils2和setuptools （也许更多）。 似乎distribute和distutils2已停止使用setuptools ，这留下了两个相互竞争的标准。

据我所知， setuptools提供了比distutils更多的选项（例如声明依赖项，测试等），但是它没有包含在Python标准库中（但是？）。

Python包装用户指南 [ 1 ]现在推荐：

使用setuptools定义项目并创建源分发。

并解释说：

尽管您可以在许多项目中使用纯distutils ，但它不支持在其他项目上定义依赖项，并且缺少一些便于实际自动填充setuptools提供的包元数据的便利实用程序。 作为标准库之外，setuptools还在不同版本的Python中提供更一致的功能集，并且（与distutils不同），将更新setuptools以在所有支持的版本上生成即将推出的“Metadata 2.0”标准格式。

即使对于选择使用distutils项目，当pip直接从源代码安装这样的项目（而不是从预构建的wheel文件安装）时，它实际上将使用setuptools来构建项目。

但是，查看各种项目的setup.py文件会发现这似乎不是一个真正的标准。 许多软件包仍然使用distutils而那些支持setuptools通常将setuptools与distutils混合setuptools ，例如通过进行后备导入：

try:
    from setuptools import setup
except ImportError:
    from distutils.core import setup

接着尝试找到一种方法来编写可由setuptools和distutils安装的设置。 这通常包括各种容易出错的依赖项检查方法，因为distutils不支持setup函数中的依赖项。

为什么人们仍然需要额外的努力来支持distutils - 这是因为setuptools不在标准库中是唯一的原因吗？ distutils有什么优点，编写只支持setuptools setup.py文件有什么缺点。

Answer 1

看看这个SO问题。 它很好地解释了所有的包装方法，并可能在某种程度上帮助回答你的问题： 分布，distutils，setuptools和distutils2之间的差异？

Distutils仍然是Python中打包的标准工具。 它包含在标准库（Python 2和Python 3.0到3.3）中。 它对于简单的Python发行版很有用，但缺少功能。 它介绍了可以在setup.py脚本中导入的distutils Python包。

Setuptools的开发是为了克服Distutils的局限性，并未包含在标准库中。 它引入了一个名为easy_install的命令行实用程序。 它还介绍了可以在setup.py脚本中导入的setuptools Python包，以及可以在代码中导入的pkg_resources Python包，用于查找随分发安装的数据文件。 它的一个问题是它对distutils Python包进行了修补。 它应该与pip一起使用。 最新版本于2013年7月发布。

所以，你可以看到setuptools应该优先于distutils，我看到你的问题来自哪里，但我不认为distutils会很快失去支持，因为，简单地说，它在很多情况下用于一些流行的遗留程序。 而且您可能知道在遗留程序中更改这些类型的东西可能会非常麻烦并且会遇到很多问题，例如不兼容性，这会导致开发人员不得不重写源代码。 所以有这个，而且distutils是标准python库的一部分，而setuptools则不是。 所以，如果你正在创建一个python程序，在这个时代，使用setuptools，但请记住，没有distutils，setuptools将永远不会存在。

Answer 2

事实上，setuptools不是标准库中唯一的原因

这是一个原因。 以下内容直接来自NumPy setup.py ：

if len(sys.argv) >= 2 and ('--help' in sys.argv[1:] or
        sys.argv[1] in ('--help-commands', 'egg_info', '--version',
                        'clean')):
    # Use setuptools for these commands (they don't work well or at all
    # with distutils).  For normal builds use distutils.
    try:
        from setuptools import setup
    except ImportError:
        from distutils.core import setup

所以NumPy更喜欢setuptools如果能找到的话。 但是SciPy曾经这样做过，直到在某些情况下它被修补为更喜欢distutils 。 引用提交日志：

Setuptools sets mode +x on the test scripts, so that Nose refuses to run
them. Better not do that.

当然， setuptools和distribute之间的合并应该在适当的时候解决所有这些，但许多软件包仍然需要支持Python 2.6安装。

Answer 3

我们仍然谈论和使用distutils有几个原因，即使setuptools毫无疑问是更好的工具集。

首先，到处都有distutils。 如果您希望构建一个模块以便与他人共享，并且没有任何复杂的要求，则可以保证在您的工作机器上可用。 如果您必须支持旧版本的python，或者您发现自己在不熟悉的环境中工作，这一点尤为重要。

其次，setuptools为distutils提供了增强功能。 因此，它是在distutils工具集之后建模的，并从那里获取所有结构。 setuptools的文档假设读者熟悉distutils并且只记录它如何增强基本工具集。 您可以认为distutils定义了方言，而setuptools则增强了该方言。

我对新项目的个人方法是从我将要使用distutils的假设开始。 只有当项目增长到需要setuptools的功能时才进行升级。 setuptools是distutils的替代品，它是我的setup.py的一行更改。

Answer 4

基本上，这是由于责任分工。

setuptools不是Python标准库的一部分，因为它由第三方而不是Python核心团队维护。 这意味着，除其他外：

• 核心测试套件不包含它，核心功能不依赖它
• 它本身并没有为附加模块设置核心标准（它们的位置，导入方式，C扩展的二进制接口等）。
• 它是独立于Python版本更新和发布的

实际上，核心团队缩小了distutils的范围，为自己保留了“核心标准”和“最少必要的编译”部分， 同时将所有内容 （扩展的编译器/包格式/任何支持） 留给 第三方。 以前覆盖那些“扩展部分”的代码因为向后兼容而变得陈旧 。

从分发Python模块 - Python 2.7.12文档 ：

虽然正在逐步淘汰distutils直接使用，但它仍然为当前的包装和分销基础设施奠定了基础，它不仅仍然是标准库的一部分，而且其名称以其他方式存在（例如邮件的名称）用于协调Python包装标准开发的列表）。

由于上述原因，其他操作系统的软件包同样可能单独提供setuptools和pip

• 并且因为它们不是必需的 - 或者甚至对可维护性有害 - 当系统上已经有另一个包管理器时。