首页 文章

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

提问于
浏览
112

Python有一个令人困惑的工具历史,可用于打包和描述项目:这些包括标准库中的 distutilsdistributedistutils2setuptools (可能更多) . 似乎 distributedistutils2 已经停止使用 setuptools ,这留下了两个相互竞争的标准 .

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

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

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

并解释说:

虽然您可以在许多项目中使用纯distutils,但它不支持在其他项目上定义依赖项,并且缺少几个便于实际自动填充setuptools提供的包元数据的便利实用程序 . 作为标准库之外,setuptools还在不同版本的Python中提供更一致的功能集,并且(与distutils不同),将更新setuptools以在所有支持的版本上生成即将推出的“Metadata 2.0”标准格式 . 即使对于选择使用distutils的项目,当pip直接从源代码安装这样的项目(而不是从预构建的wheel文件安装)时,它实际上将使用setuptools来构建项目 .

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

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

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

为什么人们还在努力支持 distutils - 事实上 setuptools 不在标准库中是唯一的原因吗? distutils 有什么优点,编写只支持 setuptools 的setup.py文件有什么缺点 .

4 回答

  • 61

    看看这个SO问题 . 它很好地解释了所有包装方法,并可能在某种程度上帮助回答您的问题:Differences between distribute, distutils, setuptools and 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将永远不会存在 .

  • 11

    是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 之间的merger应该在适当的时候解决所有这些问题,但许多软件包仍然需要支持Python 2.6安装 .

  • 9

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

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

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

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

  • 6

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

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

    • 核心功能所依赖的不是't covered by the core test suite and isn'

    • 它本身并没有设置附加模块的核心标准(它们的位置,导入方式,C扩展的二进制接口等) .

    • 它是独立于Python版本更新和发布的

    Effectively, the core team has narrowed down the scope of distutils ,为自己保留"core standards"和"minimal necessary compilation"部分 while leaving all the stuff beyond that (扩展编译器/包格式/支持) to 3rd parties. The code that was previously covering those "extended parts" was left stale 以实现向后兼容性 .

    来自Distributing Python Modules — Python 2.7.12 documentation

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

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

    • 因为他们还不是系统上的另一个包管理器 .

相关问题