Allow better control over wheel tags

[FFY00]

https://github.com/pypackaging-native/pkgconf-pypi produces platform-specific but Python-independent tags. RIght now, I don't think there's any way to expose this.

[rgommers]

IIRC this should work. Just tested with https://github.com/mesonbuild/meson-python/tree/main/tests/packages/executable, which yields:

executable-1.0.0-py3-none-linux_x86_64.whl

What would you expect if not those tags?

[FFY00]

Yes, but the code makes some assumptions that aren't true for our project.

meson-python/mesonpy/__init__.py

Lines 319 to 349 in 063fe8b

	@property
	def _has_internal_libs(self) -> bool:
	return bool(self._manifest.get('mesonpy-libs'))
	@property
	def _has_extension_modules(self) -> bool:
	# Assume that all code installed in {platlib} is Python ABI dependent.
	return bool(self._manifest.get('platlib'))
	@cached_property
	def _pure(self) -> bool:
	"""Whether the wheel is architecture independent"""
	if self._manifest['platlib'] or self._manifest['mesonpy-libs']:
	return False
	for _, file in self._manifest['scripts']:
	if _is_native(file):
	return False
	return True
	@property
	def tag(self) -> mesonpy._tags.Tag:
	"""Wheel tags."""
	if self._pure:
	return mesonpy._tags.Tag('py3', 'none', 'any')
	if not self._has_extension_modules:
	# The wheel has platform dependent code (is not pure) but
	# does not contain any extension module (does not
	# distribute any file in {platlib}) thus use generic
	# implementation and ABI tags.
	return mesonpy._tags.Tag('py3', 'none', None)
	return mesonpy._tags.Tag(None, self._stable_abi, None)

Specifically, it assumes that we are not installing platform binary files to the Python directory, and that all files in platlib are ABI-dependent.

[rgommers]

Got it, thanks. Yes, we are trying to infer tags and that isn't correct in this case. It's actually not so easy to always be 100% correct here, which is why some other build backends have an override mechanism to force the tags to be a certain value.

Let's see if we can fix the logic first though. This case (a few .py files plus an executable not dependent on the Python C API) will be needed more often in the future probably.

[rgommers]

IIRC the ninja wheel has a very similar structure.

[FFY00]

Got it, thanks. Yes, we are trying to infer tags and that isn't correct in this case. It's actually not so easy to always be 100% correct here, which is why some other build backends have an override mechanism to force the tags to be a certain value.

Yes, I think the best you we can do right now would be looking at the meson tags, but I think it'd be better to also have the option to override.

[ncoghlan]

A different-but-related use case: when building on later Python versions with Py_LIMITED_API set to limit the symbols to those published by an earlier version, I wasn't able to find a way to tell meson to set the Python tag to cp311 (the declared API version) instead of to cp312 (the build environment).

The workaround was straightforward (just rename the file afterwards), but it seemed worth mentioning as a use case if improved native support is considered in the future.

[eli-schwartz]

What would be a nice-to-have is if there was some way to analyze a compiled extension module and determine what is the minimum ABI version it uses.

glibc does something somewhat similar-ish. The "stable ABI" is libc.so.6, and looking at what symbol versions it uses of the form @GLIBC_2.XX tells you what the minimum glibc version it is compatible is. This can then be reported by auditwheel repair:

The wheel references external versioned symbols in these
system-provided shared libraries: libc.so.6 with versions
{'GLIBC_2.4', 'GLIBC_2.14', 'GLIBC_2.2.5'}

This constrains the platform tag to "manylinux_2_17_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.