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.