Python 次要版本之间的轮子不兼容答案

【问题标题】：Wheel Incompatibility between Python Minor VersionsPython 次要版本之间的轮子不兼容
【发布时间】：2020-02-14 22:04:39
【问题描述】：

我正在 PyPi 上发布一个支持 Python 3.6+ 的包，并希望构建尽可能少的轮子。

我已经阅读了Python's packaging system for wheels 并查看了NumPy project 的示例。阅读PEP 513 和PEP 571 也很有见地。

问题来了：为什么轮子前向不兼容 Python 小版本更改？

例如，从 3.5 升级到 3.6 会带来 f-strings。但似乎用 Python 3.5（不使用 f 字符串）构建的轮子应该能够在 Python 3.6 环境中正常运行。这里有什么问题？

【问题讨论】：

在 Python 3.6 中运行的 Python 3.5 代码是向前兼容的，对吧？ Python 3.6 代码（没有 f 字符串）将（可能）向后与 Python 3.5 兼容。我是不是倒过来了？
正确。我的问题是，如果我的包在 Python 3.5 上运行良好，我是否还需要发布 3.6 的轮子，或者如果用户运行的是 3.6，3.5 的轮子就足够了吗？例如，NumPy 与 Python 3.5+ 兼容，但它们为每个次要版本发布了轮子。

【解决方案1】：

用纯 Python 以 2 和 3 兼容的方式编写的代码可以在通用轮子中发布。一个适合所有 Python 版本的轮子。示例：https://pypi.org/project/SQLObject/#files

但是，包含用 C 编写的模块的项目必须针对每个平台（处理器架构和 32/64 位）、操作系统和 Python 版本单独发布，因为 C 代码必须以不同的方式编译。示例：https://pypi.org/project/Cheetah3/#files

附言。全面披露：我是用作示例的两个项目的维护者。

【讨论】：