twine上传含C扩展Python包遇linux_x86_64标签不支持问题咨询

所有方案无需额外搭建复杂的manylinux构建环境，直接可落地：

• 可直接删除dist目录下生成的qjson2json-0.0.0-cp38-cp38-linux_x86_64.whl文件。这类在通用本地Linux环境下直接构建的平台专属wheel，本身不符合PyPI公开分发规范，上传时必然被拦截，没有对外分发的实际价值，删除后剩余的源码tar.gz包可正常完成上传，操作完全合规。
• 完全可以配置工具实现仅上传源码tar.gz包，无需每次手动清理文件：
  • 手动上传场景下，使用twine上传时不要指定整个dist目录的全量文件，直接在命令后明确指定要上传的tar.gz文件路径即可，例如执行twine upload dist/qjson2json-0.0.0.tar.gz，就不会把同目录下不符合规范的whl文件一并提交。
  • 自动化CI上传场景下，可在上传步骤增加文件过滤逻辑，仅匹配tar.gz后缀的构建产物作为上传目标，直接跳过所有whl类型的文件。
• 完全可以在构建环节直接跳过这类无用原生whl的生成，从根源减少冗余文件：
  • 传统setuptools构建流程下，不要执行sdist + bdist_wheel的组合构建命令，只运行源码打包命令python setup.py sdist，构建完成后dist目录内只会生成源码tar.gz，不会产出平台专属的原生whl。
  • 遵循PEP 517规范的现代pyproject.toml构建流程下，执行构建命令时增加--sdist参数指定仅构建源码包，例如运行python -m build --sdist，命令执行全程不会触发平台专属whl的构建逻辑，自然不会生成这类无效文件。

注意：带C扩展的源码包上传PyPI后，用户本地安装时会自动触发C代码的本地编译流程，只要用户本地环境有对应版本的C编译器，就可以正常完成安装。对于单C文件的小型项目来说，这种分发方式完全可以满足使用需求，不需要额外投入精力维护多平台预编译wheel的构建流程。

内容的提问来源于stack exchange，提问作者chmike