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

Question

Python就可以用于打包和描述项目的工具,一个令人困惑的历史:这些包括distutils标准库中,distribute,distutils2,和setuptools(也许更多).看来,distribute和distutils2赞成被中止setuptools,这让两个相互竞争的标准.

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

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

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

并解释说:

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

即使是那些选择使用的项目distutils,当pip直接从源代码安装这样的项目时(而不是从预先构建的wheel文件安装),它实际上会使用setuptools而不是使用它来构建项目.

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

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

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

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

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不是标准库中唯一的原因

这是一个原因.以下内容直接来自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

所以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单独提供

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