为什么在 packaging.sys_tags() 中,较低的 CP 版本比没有实现规范的 PY 版本具有更高的优先级?

why in the packaging.sys_tags() the lower cp version has higher priority than the py version which has no implementation spec?

提问人:Wang 提问时间:11/10/2023 更新时间:11/10/2023 访问量:26

问:

从文档:

对可迭代对象进行排序,以便最匹配的标记在序列中排在第一位。标记的确切优先顺序是特定于解释器的,但通常标记重要性的顺序为:

  1. 译员
  2. 平台
  3. ABI公司

我希望 py310 在 cp39 之前,但是 pynn 总是在底部:

import packaging.tags
print(list(dict.fromkeys(i.interpreter for i in packaging.tags.sys_tags())))
['cp310',
 'cp39',
 'cp38',
 'cp37',
 'cp36',
 'cp35',
 'cp34',
 'cp33',
 'cp32',
 'py310',
 'py3',
 'py39',
 'py38',
 'py37',
 'py36',
 'py35',
 'py34',
 'py33',
 'py32',
 'py31',
 'py30']

这是否意味着如果我有旧包和新包,鉴于当前系统是 cp310,它实际上更喜欢旧包而不是新的 py310-none-any?我无法解决这个问题。为什么顺序应该是这样的?cp36-abi3-manylinux_2_35_x86_64py310-none-any

蟒蛇 python打包

评论


答:

1赞 wim 11/10/2023 #1
  1. ...旧软件包 cp36-abi3-manylinux_2_35_x86_64 和新软件包 py310-none-any

那不是“旧包”和“新包”,而更像是“平台特定包”和“通用包”。他们会是同龄人。

compat 标记与发行版本身的版本号无关。只有在已选择包的特定版本时,才考虑优先考虑可用文件。

  1. 为什么顺序应该是这样的?

根据文档

建议安装程序在回退到为旧 Python 版本发布的纯 Python 版本之前,尝试选择可用的功能最完整的构建发行版(最特定于安装环境的发行版)。

据推测,对于构建的发行版,您能负担得起的越具体,您就越有机会进行特定于平台的优化等。在构建和发布轮子时,在考虑广泛兼容性与高级功能的竞争需求时,可能需要做出一些权衡。

Python 代码中的类比可能是:如果你想使用更酷的新语言功能(例如使用 f-strings),你必须降低兼容性(例如限制为 Python 3.6+)。

评论

0赞 Wang 11/10/2023
但是 CP36 会与 CP310 兼容吗?我怀疑。从 packaging.python.org/en/latest/specifications/...,该示例也只在 py33 前面显示 cp33 和 cp3,这是有道理的。我认为没有 <cp310 的输出会更有意义。并且 pip 的行为也符合预期。它永远不会为 cp310 系统选择 cp36。
0赞 wim 11/10/2023
据我了解,是的,cp36 标记的 wheel 应该与 CPython 3.10 兼容。不要引用我的话,但我认为该标签的意思是 cpython >= 3.6,而不是 cpython == 3.6。是的,如果索引中没有更好的 cp10 轮可用,pip 将在 3.10 运行时选择 cp36 轮。用于显示 pip 安装程序的兼容标记(和优先级)。pip debug -v
0赞 wim 11/10/2023
文档中的那个例子有点奇怪/模糊。它说“此示例列表适用于在 linux_x86_64 系统上运行在 CPython 3.3 下的安装程序”......嗯......什么安装程序?皮普还是别的什么?或者它只是一些虚构的假设安装程序?我不太明白他们在那里试图传达什么。
0赞 Wang 11/10/2023
嗯。。。这根本不是真的。我有很多次较高的 python 次要版本会破坏较低的 python 次要版本。这就是为什么在 setup.py 中您可以指定类似 python_requires <3.9 的内容,好吧,我想这意味着当这种情况发生时,我将需要更改 setup.py 然后提升包版本,而不仅仅是重新构建/上传 whl,那么问题当然永远不会发生。