Built distributions may be platform specific for reasons other than C extensions, such as by including a native executable invoked as a subprocess.
As of today, there is no way for wheel to give the proper tagging. The only two names wheel are given today are:
(impl, "none", plat_name) for a python package that does not contains any extension module or C libraries
(impl, abi_tag, plat_name) otherwise
The presence of an extention module is not enough to assume that the content of the wheel is ABI dependent. Executables could be build by extension and included in the package, but be independent from python.
There is a need for (impl, "none", plat_name) even when an extension exists.
I would be open to do the code change if we agree on the approach. I suggest adding an option to specify that the wheel is pure, and it would take precendence over the current default of checking for extension or C libraries.
All this lives in setuptools now. As far as this project (a CLI tool) goes, it is very much supported; just use wheel tags --abi-tag=none <original-wheel> for example to change the tag on an existing wheel.
According to the specification : https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/#use
As of today, there is no way for wheel to give the proper tagging. The only two names wheel are given today are:
(impl, "none", plat_name)
for a python package that does not contains any extension module or C libraries(impl, abi_tag, plat_name)
otherwiseThe presence of an extention module is not enough to assume that the content of the wheel is ABI dependent. Executables could be build by extension and included in the package, but be independent from python.
There is a need for
(impl, "none", plat_name)
even when an extension exists. I would be open to do the code change if we agree on the approach. I suggest adding an option to specify that the wheel ispure
, and it would take precendence over the current default of checking for extension or C libraries.