Support musllinux tags

[lu-zero]

The current crossenv does not seems to be aware of them.

[waterfoul]

Looks like it's an issue with the indirection script

Traceback (most recent call last): File "", line 2, in File "/venvs/ansible-lint/cross/lib/python3.11/site-packages/packaging/_elffile.py", line 53, in init raise ELFInvalid(f"invalid magic: {magic!r}") packaging._elffile.ELFInvalid: invalid magic: b'#!/v'

I see at the bottom of that script that it's trying to fix sys.executable but it's not working

>>> sys.executable
'/venvs/ansible-lint/cross/bin/python3'

# This will fix up argv0 so that sys.executable will be correct
os.execv('/venvs/ansible-lint/build/bin/python3', sys.argv)

Also shows here

(cross) /venvs/ansible-lint # pip3 debug --verbose 
WARNING: This command is only meant for debugging. Do not use this with automation for parsing and getting these details, since the output and options of this command may change without notice.
pip version: pip 22.3.1 from /venvs/ansible-lint/build/lib/python3.11/site-packages/pip (python 3.11)
sys.version: 3.11.3 (main, May  3 2023, 08:11:32) [GCC 12.2.1 20220924]
sys.executable: /venvs/ansible-lint/cross/bin/python3

[waterfoul]

Oh, I see. it's setting it correctly which breaks the packaging package

[waterfoul]

If you run find . -type f -name _musllinux.py -exec sed -i 's|def _get_musl_version.*:|\0\n return _MuslVersion(major=1, minor=2)|g' \{\} \; before running pip it enables the musl wheels. Make sure you adjust the major and minor versions to match your cross system's musl which can be found by running /lib/ld-musl-*.so.1

[benfogle]

It is unfortunate that PEP656 didn't include an escape hatch like PEP600 did. There's no official way for us to override the musllinux tags like we can for manylinux tags. That means this is one of those situations where we have to be "right" and "wrong" at the same time: there are places where libraries expect to be able to run sys.executable (so it needs to be build-python) and places where they expect it to be the on target binary (so it needs to be host-python).

I think we'll need to supply a patch to packaging to get around this, basically what @waterfoul suggested. (We might also be able to patch open() itself so that open(sys.executable) opens host-python, since this is not the only place I've run into this... but that seems awful even by my standards.)

[waterfoul]

You will need to patch packging. Packaging opens the executable in order to find the path the /lib/ld-musl-*.so.1 of the host and executes it to find the version. This won't work on the build system since the .so (being of a different architecture) won't execute. You could potentially set it up so you must cross build alpine on the same version of alpine with the same lib/ld-musl version but passing in the version number would be simpler.