Problems with platform handling
In https://www.python.org/dev/peps/pep-0425/#platform-tag the platform portion of the wheel tag is defined in terms of distutils.util.get_platform(). That, in turn is defined in terms of the os and architecture that the python interpreter is running on: https://docs.python.org/3/distutils/apiref.html#distutils.util.get_platform platforms is not present in pep 621 (about standard pyproject.toml fields) as it is determined at build time, not by a static definition in a config file, but there is a platforms field in mesonpep517's config. This ticket outlines issues with both that config option and mesonpep517's autodeection of what the platform tag should be.
-
The documentation of platforms says that it can be "
'any', py3, etc...
".any
is a valid platform, however, py3 is not. Platforms should be more like win32 or manylinux2014. I found the present wording in the following places: -
We usually get an accurate platform ourselves (via get_platform_tag() in https://gitlab.com/thiblahute/mesonpep517/-/blob/master/mesonpep517/pep425tags.py#L128 or
any
for pure python builds). So it probably does not make sense for the user to set this in pyproject.toml. So maybe we want to remove the platforms config option and rely on autodetection. However, there are the following two caveats with the current code so we probably want to let the user continue to use the config to override our detection until these cases are solved: -
meson makes it possible to cross-compile python c extensions (https://mesonbuild.com/Cross-compilation.html ). The implementation of get_platform_tag() ( https://gitlab.com/thiblahute/mesonpep517/-/blob/master/mesonpep517/pep425tags.py#L128 ) only checks the host that we're running on so it won't know about any cross-compilation target. I'm not sure how we want to expose cross compilation to the user so I'm not sure what we'd need to do to get the platform that meson was targeting back. Additionally, I am pretty sure that meson will use a representation of platform that makes sense to gcc/clang/ninja while we need a representation that makes sense to python. So we're probably going to need to do some parsing and mapping between the two. Python may have some routines to do that when the interpreter is built but I haven't looked to see whether it's exposed in a python library.
-
get_platform_tags() doesn't appear to take manylinux into account. There may be a mapping between certain strings returned by
distutils.util.get_platform()
and manylinux$VERSION in setuptools or something. I've read a few mailing list threads but they've left me with more questions. The latest manylinux incarnation seems to say that the tag is determined just by examining the glibc version that the wheel is compiled against. However, that leaves me wondering what happens to all of the other libraries that are linked against. Do those have to be statically compiled into the extension? There's also talk about auditwheel, a tool which checks whether a wheel can be run on multiple different linux distros (and other platforms) as being the actual check of whether something is really suitable for the manylinux tag. That sounds like we might need to let the user override the platform tag of compiled extensions forever?