python - 如何以及谁应该将 wheel 指定为 Python 包依赖项？

Question

我正在编写要在框架应用程序（特别是 Amazon SageMaker 的TensorFlow 服务容器- 运行 Python 3.5）中安装和执行的源包（不是完全打包的模块，而是一些具有依赖项的脚本）。

我的依赖项之一是matplotlib，它又需要kiwisolver，它具有 C++ 组件。

似乎我的目标容器默认没有wheel安装，因为当我只提供一个requirements.txt文件时，我收到“为什么 python setup.py 在 Travis CI 上说无效命令 'bdist_wheel'？”中描述的错误。.

我想我是通过提供一个setup.py代替它来工作的，正如特拉维斯 CI 问题的答案setup_requires=["wheel"]中所建议的那样。

我的 Python 打包功能很弱，所以我的问题是：谁应该指定这个依赖项，因为它似乎不应该是我？

• kiwisolver 应该做它需要的广告wheel吗？
• 安装用户代码模块的框架应用程序/环境是否requirements.txt有一个隐含的合同wheel可以在环境中使用，出于某种原因在 Python 的包装理念中？
• 也许我真的知道这一点，因为我间接使用了像 kiwisolver 这样的模块，所以我的包需要wheel设置并且直线pip install -r requirements.txt不起作用？

如果有人能解释这个答案是否随着PEP 518和弃用setup_requires:S而改变，那就更好了

标签： pythonsetuptoolspython-wheelpython-packaging

Answer 1

通常轮子可以被认为是构建时依赖而不是安装时依赖。但实际上，wheel只是分发 Python 项目（库或应用程序）的一种方式，因此它通常不是强制依赖项。

构建库的一个系统（kiwisolver）可能需要安装轮工具。但是如果我没记错的话，最近版本的pip已经捆绑了轮子，所以现在通常不需要显式安装它。

在许多情况下，已经在PyPI上构建了可用的轮子。但有时没有与目标系统兼容的轮子（Python 解释器版本、操作系统、CPU 位数）。在您的情况下，kiwisolver有多种可用的轮子，但不适用于Python 3.5。

因此，您要安装kiwisolver的系统似乎与PyPI上可用的任何轮子都不兼容。所以pip必须在本地构建它。通常pip会尝试先构建一个轮子，但据我所知，如果无法构建一个轮子，这不会破坏交易，那么pip通常只是继续并安装项目，而无需进入轮子中间步骤。

但是pip仍然必须能够构建库，这可能需要一些 C/C++ 编译器或在本地系统上满足其他不寻常的条件。这就是为什么将库作为轮子分发非常舒适的原因，因为构建步骤已经完成。

所以总结一下，从我的角度来看，没有人真的需要将wheel声明为依赖项或安装wheel，除非他们真的想要构建wheel。但轮子真的只是一个中间可选步骤。这是一种分发 Python 项目（库或应用程序）的方式。我不认为绝对需要将轮子添加到setuptools ' setup_requires（已弃用或接近它）或pyproject.toml's build-system.requires，它更多的是（非常常见和准标准的）便利。

现在在你的情况下我会怎么做？

• 在从requirements.txt包含kiwisolver的文件（直接或间接）安装之前，请确保pip是最新的或显式安装wheel，并且：
  • 使用PyPI上已经提供轮子的 Python 版本。
  • 如果您想继续使用Python 3.5：
    • 确保目标系统能够自己构建kiwisolver（可能需要 C/C++ 编译器和其他一些本地库）。