python - py编写 - setuptools vs. distutils:为什么distutils仍然是一件事?




python setuptools extension (3)

Python有一个令人困惑的工具历史记录,可用于打包和描述项目:这些工具包括标准库中的distutils2distributedistutils2setuptools (以及更多)。 似乎distributedistutils2停止赞成setuptools ,这留下了两个相互竞争的标准。

据我了解, setuptoolsdistutils提供了更多的选择(例如声明依赖关系,测试等),但它并未包含在Python标准库中(还有?)。

Python打包用户指南 [ 1 ]现在推荐:

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

并解释说:

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

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

但是,查看各种项目的setup.py文件显示,这似乎不是一个实际的标准。 许多软件包仍然使用distutils而那些支持setuptools通常setuptoolsdistutils混合setuptools ,例如通过执行回退导入:

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

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

为什么人们仍在额外努力支持distutils - setuptools不在标准库中的唯一原因是什么? distutils的优点是什么,并且有没有写仅支持setuptools setup.py文件的缺点。


事实上,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会这样做,直到在某些情况下patched偏好distutils 。 引用提交日志:

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

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


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

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

  • 它不被核心测试套件覆盖,核心功能也不依赖它
  • 它本身并不为加载模块设置核心标准(它们的位置,导入方式,C扩展的二进制接口等)。
  • 它是独立于Python发行版而更新和发布的

实际上,核心团队已经缩小了distutils的范围,为自己保留了“核心标准”和“最少必要的编译”部分, 同时将所有内容 (扩展编译器/封装格式/任何支持) 留给 第三方。 以前覆盖这些“扩展部分”的代码对于向后兼容性而言是陈旧的。

分布式Python模块 - Python 2.7.12文档

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

出于上述原因,其他操作系统的软件包同样可能会分别提供setuptoolspip

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

看看这个。 它很好地解释了所有的打包方法,并可能在一定程度上帮助回答你的问题: webpage

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将永远不会存在。





distutils