mesonbuild / meson-python

Meson PEP 517 Python build backend
https://mesonbuild.com/meson-python/
MIT License
117 stars 59 forks source link

Allow better control over wheel tags #639

Open FFY00 opened 1 month ago

FFY00 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

https://github.com/mesonbuild/meson-python/blob/063fe8bc8ad6984c29b24a0f72a14e1ced091a9c/mesonpy/__init__.py#L319-L349

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 commented 1 month ago

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 commented 1 month ago

IIRC the ninja wheel has a very similar structure.

FFY00 commented 1 month ago

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.