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

Question

我正在编写一个源代码包（不是一个完全打包的模块，而是一些具有依赖关系的脚本），在框架应用程序（特别是Amazon SageMaker运行Python 3.5的TensorFlow serving container）中安装和执行

我的一个依赖项是^ {CD1>}，而这又需要^ {CD2>}，它有C++组件。

默认情况下，我的目标容器似乎没有安装wheel，因为当我只提供一个requirements.txt文件时，会出现"Why is python setup.py saying invalid command 'bdist_wheel' on Travis CI?"中描述的错误

我想我通过提供一个{}来实现它，而不是像travisci问题的{{a3}中建议的{}

我的Python包很弱，所以我的问题是：谁应该指定这个依赖项，因为看起来不应该是我

• kiwisolver是否应该宣传它需要wheel
• 一个通过requirements.txt安装用户代码模块的框架应用程序/环境是否有一个隐式契约，以使wheel在环境中可用，这是因为Python的打包风格中的某些原因
• 也许我真的应该知道，因为我间接地使用了kiwisolver这样的模块，所以我的包需要wheel进行设置，而直接的pip install -r requirements.txt无法工作

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

Answer 1

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

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

在许多情况下，PyPI上已经有了轮子。但有时没有与目标系统兼容的控制盘（Python解释器版本、操作系统、CPU位）。在你的例子中，kiwisolver has a wide range of wheels available but not for Python 3.5

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

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

总而言之，从我的观点来看，没有人真正需要将车轮声明为依赖项或安装车轮，除非他们真的想要建造车轮。但是轮子实际上只是一个可选的中间步骤。它是一种分发Python项目（库或应用程序）的方法。我不认为绝对需要将轮子添加到设置工具setup_requires（这是不推荐的或接近它的）中，也不需要添加到pyproject.toml{}，它更像是一种（非常常见且准标准的）便利

在你的情况下我该怎么办

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