Python setuptools 与 distutils：为什么 distutils 仍然是一个东西？

setuptools vs. distutils: why is distutils still a thing?

提问by cel

Python has a confusing history of tools that can be used to package and describe projects: these include distutilsin the Standard Library, distribute, distutils2, and setuptools(and maybe more). It appears that distributeand distutils2were discontinued in favor of setuptools, which leaves two competing standards.

Python 在可用于打包和描述项目的工具方面有着令人困惑的历史：这些包括distutils在标准库distribute、distutils2、 和setuptools（可能还有更多）中。似乎distribute和distutils2已停止支持setuptools，这留下了两个相互竞争的标准。

To my understanding setuptoolsoffers far more options (e.g. declaring dependencies, tests, etc.) than distutils, however it is not included in the Python standard library (yet?).

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

The Python Packaging User Guide[1] recommends now:

所述的Python包装用户指南[ 1]现在建议：

Use setuptoolsto define projects and create Source Distributions.

使用setuptools定义的项目和创建源代码分发。

And explains:

并解释说：

Although you can use pure distutilsfor many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating package metadata correctly that are provided by setuptools. Being outside the standard library, setuptools also offers a more consistent feature set across different versions of Python, and (unlike distutils), setuptoolswill be updated to produce the upcoming “Metadata 2.0” standard formats on all supported versions.

Even for projects that do choose to use distutils, when pip installs such projects directly from source (rather than installing from a prebuilt wheel file), it will actually build your project using setuptoolsinstead.

尽管您可以将 puredistutils用于许多项目，但它不支持定义对其他项目的依赖关系，并且缺少由setuptools. 在标准库之外，setuptools 还提供了跨不同 Python 版本的更一致的功能集，并且（与 不同distutils）setuptools将更新以在所有支持的版本上生成即将推出的“元数据 2.0”标准格式。

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

However, looking into various project's setup.pyfiles reveals that this does not seem to be an actual standard. Many packages still use distutilsand those that support setuptoolsoften mix setuptoolswith distutilse.g. by doing a fallback import:

然而，查看各种项目的setup.py文件表明这似乎不是一个实际的标准。许多包仍在使用，distutils而那些支持的包setuptools经常setuptools与distutils例如通过执行回退导入混合使用：

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

Followed by an attempt to find a way to write a setup that can be installed by both setuptoolsand distutils. This often includes various ways of error-prone dependency checking, since distutilsdoes not support dependencies in the setup function.

其次是试图找到一种方法来编写可以由setuptools和安装的安装程序distutils。这通常包括各种容易出错的依赖项检查方法，因为distutils在 setup 函数中不支持依赖项。

Why are people still making the extra effort to support distutils- is the fact that setuptoolsis not in the standard library the only reason? What are the advantages of distutilsand are there any drawbacks of writing setup.pyfiles that only support setuptools.

为什么人们仍然付出额外的努力来支持distutils-setuptools标准库中没有的事实是唯一的原因吗？有什么优势distutils以及是否有书面的任何缺点setup.py文件只支持setuptools。

回答by Fred Foo

is the fact that setuptools is not in the standard library the only reason

setuptools 不在标准库中是唯一的原因

That's one reason. The following is straight from the NumPy setup.py:

这是原因之一。以下直接来自NumPysetup.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

So NumPy prefers setuptoolsif it can find it. But then SciPy used to do this, until it was patchedto prefer distutilsin some situations. Citing the commit log:

所以 NumPy 更喜欢setuptools它能找到它。但随后SciPy的使用要做到这一点，直到它被修补喜欢distutils在某些情况下。引用提交日志：

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

Of course, a mergerbetween setuptoolsand distributeshould resolve all this in due time, but many packages still need to support Python 2.6 installations.

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

回答by Fred Foo

Have a look at this SO question. It explains all the packaging methods very well, and might help answer your question to some extent: Differences between distribute, distutils, setuptools and distutils2?

看看这个 SO 问题。它很好地解释了所有的打包方法，并且在一定程度上可能有助于回答您的问题：distribute, distutils, setuptools 和 distutils2 之间的差异？

Distutilsis still the standard tool for packaging in Python. It is included in the standard library (Python 2 and Python 3.0 to 3.3). It is useful for simple Python distributions, but lacks features. It introduces the distutils Python package that can be imported in your setup.py script.

Setuptoolswas developed to overcome Distutils' limitations, and is not included in the standard library. It introduced a command-line utility called easy_install. It also introduced the setuptools Python package that can be imported in your setup.py script, and the pkg_resources Python package that can be imported in your code to locate data files installed with a distribution. One of its gotchas is that it monkey-patches the distutils Python package. It should work well with pip. The latest version was released in July 2013.

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 月发布。

So, as you can see setuptools should be preferred to distutils, and I see where your question comes from, however I don't see distutils losing support anytime soon, as, simply put, it is used in many cases with some popular legacy programs. And as you probably know changing these sorts of things in legacy programs can be quite a pain and come with quite a few problems, for example incompatibilities, which would then lead to the developer having to rewrite the source code. So there is that, and also the fact that distutils is a part of the standard python library whereas setuptools is not. So, if you are creating a python program, in this day and age, use setuptools, however keep in mind that without distutils, setuptools would have never existed.

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

回答by user590028

There are several reasons we still talk about and use distutils, even though setuptools is without a doubt the better tool set.

我们仍在谈论和使用 distutils 的原因有很多，尽管 setuptools 无疑是更好的工具集。

Firstly, distutils is available everywhere. If you are looking to build a module for sharing with others, and don't have any complicated requirements, it is guaranteed to be available on your work machine. This is particularly important if you have to support older versions of python, or if you find yourself working in an unfamiliar environment.

首先，distutils 随处可用。如果您正在寻找构建一个与他人共享的模块，并且没有任何复杂的要求，那么它保证在您的工作机器上可用。如果您必须支持旧版本的 Python，或者您发现自己在一个陌生的环境中工作，这一点尤其重要。

Secondly, setuptools provides enhancements to distutils. It is therefore modeled after the distutils tool set and takes all of it's structure from there. The documentation for setuptools assumes the reader is familiar with distutils and only documents how it enhances the base tool set. You can think of it that distutils defines the dialect and setuptools enhances that dialect.

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

My personal approach for new projects is start with the assumption I'm going to use distutils. Only as the project grows to require a feature of setuptools do I make the upgrade. The setuptools is a drop-in-replacement for distutils, it's a one-line change to my setup.py.

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

回答by ivan_pozdeev

Basically, it's due to the division of responsibilities.

基本上，这是由于职责分工造成的。

setuptoolsis not a part of Python standard library because it's maintained by a 3rd party rather than Python core team. Which means, among other things:

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

• it isn't covered by the core test suite and isn't relied upon by core functionality
• it doesn't itselfset core standards for add-on modules (their location, means of import, C extensions' binary interface etc.).
• it's updated and released independently from Python releases

• 它不包含在核心测试套件中，也不依赖于核心功能
• 它不本身为附加模块（它们的位置，进口的手段，C附加信息二进制接口等）设定核心标准。
• 它的更新和发布独立于 Python 版本

Effectively, the core team has narrowed down the scope of distutils, reserving the "core standards" and "minimal necessary compilation" parts for themselves while leaving all the stuff beyond that(extended compiler/package format/whatever support) to 3rd parties. The code that was previously covering those "extended parts" was left stalefor backwards compatibility.

实际上，核心团队缩小了 distutils 的范围，为自己保留了“核心标准”和“最小必要编译”部分，而将除此之外的所有内容（扩展编译器/包格式/任何支持）留给了3rd 方。为了向后兼容，以前覆盖那些“扩展部分”的代码已经过时了。

From Distributing Python Modules — Python 2.7.12 documentation:

来自分发 Python 模块 — Python 2.7.12 文档：

While direct use of distutilsis being phased out, it still laid the foundation for the current packaging and distribution infrastructure, and it not only remains part of the standard library, but its name lives on in other ways (such as the name of the mailing list used to coordinate Python packaging standards development).

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

Packages for other OSes are likewise likely to provide setuptoolsand pipseparately - for the aforementioned reasons

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

• and because they aren't necessary - or are even detrimental for maintainability - when there's already another package manager on the system.

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