Installing the pre-built v0.2.85 – v0.3.0 Metal wheels for Python 3.9 – 3.12 yields `Bad magic number for file header`

[lsorber]

Expected Behavior

Installing the pre-built v0.2.85 Metal wheels works for all supported versions of Python.

Current Behavior

Installing the pre-built v0.2.85 Metal wheels for Python {3.10, 3.11} yields Bad magic number for file header. The Python {3.9, 3.12} versions work as expected.

Environment and Context

macOS 14 on a MacBook Pro M1 Max

Steps to Reproduce

You can test this by downloading the wheels and trying to decompress them:

Decompressing fails for:

• https://github.com/abetlen/llama-cpp-python/releases/download/v0.2.85-metal/llama_cpp_python-0.2.85-cp310-cp310-macosx_11_0_arm64.whl
• https://github.com/abetlen/llama-cpp-python/releases/download/v0.2.85-metal/llama_cpp_python-0.2.85-cp311-cp311-macosx_11_0_arm64.whl

Decompressing works for:

• https://github.com/abetlen/llama-cpp-python/releases/download/v0.2.85-metal/llama_cpp_python-0.2.85-cp39-cp39-macosx_11_0_arm64.whl
• https://github.com/abetlen/llama-cpp-python/releases/download/v0.2.85-metal/llama_cpp_python-0.2.85-cp312-cp312-macosx_11_0_arm64.whl

[lsorber]

Update: I see that the pre-built v0.2.85 Metal wheels produced by the GitHub Actions workflow seem to work fine [1], so the issue must be with the way that the artifacts are turned into a release.

[1] https://github.com/abetlen/llama-cpp-python/actions/runs/10183985970

[lsorber]

Still an issue for v0.2.86 and v0.2.87. Interestingly, for v0.2.86 only the Python 3.10 version works.

[lsorber]

Still an issue for all v0.3.0 Metal builds: https://github.com/abetlen/llama-cpp-python/releases/tag/v0.3.0-metal. To verify that this is an issue, simply download the wheel file and try to decompress it.

[lsorber]

@abetlen A few observations:

1. ✅ The Build wheels on macos-13|14|15 jobs produce working wheels, individually. You can test this by downloading them and then unarchiving them (e.g., see the run for the 0.3.5 release).
2. 💥 The Release job downloads those macos-13|14|15 artifacts and 'merges' them. I'm not sure how the merging happens, but it appears that this is what breaks the resulting wheels.

Possible solution:

1. 💡 Since the target architecture is macosx_11_0_arm64, I'm not sure it makes sense to have a matrix build for macos-13|14|15 in the first place. I think a solution could be to simply reduce the matrix to e.g. os: [macos-15], as this would result in a single set of wheels and would obviate the need to merge the artifacts.
2. 💡 In addition (but completely optional), you could consider increasing the target architecture to macOS 12 (from 2021) or macOS 13 (from 2022), which introduced Metal 2.4 and Metal 3, respectively.