我试图强制我正在构建的Python3非通用轮子成为平台轮子,尽管在分发打包过程中没有发生任何本机构建步骤。
该轮子将包含一个特定于操作系统的共享库,但该库是由一个更大的构建系统构建并复制到我的包目录中的,而我的包对此一无所知。当我的 Python3 包准备好构建到轮子中时,我的构建系统已经构建了本机共享库并将其复制到包目录中。
This SO 帖子详细介绍了适用于现已弃用的
setup.py
方法的解决方案,但我不确定如何使用新的现在标准的 build
/ pyproject.toml
系统来实现相同的结果:
mypackage/
mypackage.py # Uses platform.system and importlib to load the local OS-specific library
pyproject.toml
mysharedlib.so # Or .dylib on macOS, or .dll on Windows
根据执行构建的主机操作系统,我希望生成的轮子为
manylinux
、macos
或 windows
。
我用
python3 -m build --wheel
构建,并且总是发出 mypackage-0.1-py3-none-any.whl
。
我必须更改什么才能强制构建发出平台轮?
2023 年 9 月 2 日更新:
-C=--build-option=--plat {your-platform-tag}
不再起作用,所以我将我首选的替代品添加到列表末尾。
==========
好的,经过一些研究和阅读代码,我可以提供一些信息和一些可能满足其他人需求的解决方案,总结如下:
首先,
pyproject.toml
与setup.py
并不相互排斥。如果您通过 setuptools
创建分发包并且不存在 python3 setup.py ...
文件,pyproject.toml
将抱怨弃用。
但是,
setup.py
仍然可用,但重复项目配置值是错误的(name
、version
等)。因此,请在 pyproject.toml
文件中放入尽可能多的内容,并使用 setup.py
来覆盖 Distribution
类或覆盖 bdist_wheel
模块等。
就创建平台轮而言,有几种可行的方法,各有利弊:
此处所述覆盖
bdist_wheel
中的 setup.py
命令类,并在 self.root_is_pure
覆盖中将 finalize_options
设置为 False。这会强制设置 python 标签(例如 cp39
)以及平台标签。here所述重写
Distribution
中的setup.py
类,并重写has_ext_modules()
以简单地返回True。这也强制设置 python 和平台标签。-C=--build-option=--plat {your-platform-tag}
添加到构建调用中(例如,对于我的情况是 python -m build -w -n
)。这使得 Python 标签保持不变,但您必须提供自己的标签;没有办法说“使用任何本机平台”。导入 wheel.bdist_wheel.get_platform(pathlib.Path('.'))
和 pathlib
包后,您可以使用命令 wheel.bdist_wheel
找到确切的平台标签,但这可能很麻烦,因为 wheel
不是标准库包。mypkg-py3-none-any.whl
重命名为 mypkg-py3-none-macosx_13_0_x86_64.whl
- 平台标签似乎仅编码到文件名中,而不是在分发包过程中生成的任何包元数据。wheel
软件包实用程序更新标签,将纯轮子变成平台轮子。 python -m wheel tags --platform-tag macosx_13_0_x86_64 mypkg-py3-none-any.whl
将发出一个带有您想要的标签的新平台轮。最后我选择了最终选项,因为它需要最少的工作量 - 不需要引入
setup.py
文件来完成此任务,并且构建日志清楚地表明平台轮(不是纯粹的轮)是正在创建中。