Add information about lack of possibility of cross compile Poetry

[Czaki]

Based on discussion form #1415 I think that it is a good idea to add information about such a problem to the documentation.

[azagniotov]

Hello Team, with regards to #1415 that caused the current PR, I would like to clarify that I can to cross-compile project that uses Poetry as a build backend. Perhaps it is my understanding but this documentation change is a little confusing (at least to me)

To elaborate, I can compile

1. arm64 compatible wheel on MacOS (x86_64) runner
2. arm64 compatible wheel on Linux (x86_64) runner

In case of#1, the compiled wheel filename just contained x86_64 in it, instead of arm64, which is why I raised the ticket. But, a Apple Silicon M1 mac client was successfully able to download, install and execute the wheel in another Poetry-based project.

[Czaki]

This is put in the section about cross-compiling MacOS wheels. Cross-compilation of Linux ARM works differently than cross-compilation on MacOS.

And the wrong name of the produced wheel is, for me something that makes the building wheel not work.

If you have instructions that will allow you to build the wheel in a way that allows you to upload them directly from CI to PyPI without manual intervention, then this warning such be replaced.

At this moment, I do not have such a project and M1 machine that will allow validating such instruction.

[azagniotov]

Perhaps my comment intention was not clear and I could have articulated myself more clearly - I did not mean that the warning should not be added at all. Thank you for clarifying your thoughts and intention.

[TeoZosa]

If you have instructions that will allow you to build the wheel in a way that allows you to upload them directly from CI to PyPI without manual intervention, then this warning such be replaced.

Chiming in since I maintain a project which came across this same issue.

What are we defining as "manual intervention"? Looking at #1415, it looks like @azagniotov included instructions to build the wheel which would allow them to be uploaded from CI to PyPI. Namely, by setting the CIBW_REPAIR_WHEEL_COMMAND_MACOS env var like so (which is exactly how my project resolves this issue as well):

...
    steps:
      - uses: actions/checkout@v3
      - name: Build wheels
        uses: pypa/cibuildwheel@v2.12.0
        env:
          CIBW_REPAIR_WHEEL_COMMAND_MACOS: >
            delocate-wheel --require-archs {delocate_archs} -w {dest_dir} -v {wheel} &&
            for file in {dest_dir}/*.whl ; do mv $file ${file//x86_64/arm64} ; done
          ...
          CIBW_ARCHS_MACOS: "arm64"
          ...
...

[Czaki]

This solution is really bad as it skip whole delocate steep (as delocate will look fot x86 libs and dependencies)

[azagniotov]

@Czaki you raise a good point re To have the correct workflow you need to first rename the wheel file and then execute delocate on renamed file. <= thank you for your guidance and observation, I will look into this 👍 Much appreciated

[azagniotov]

@Czaki I followed your pointer and swapped the order of operations where:

1. The wheel was renamed first
2. The execute delocate command was on the renamed wheel

CIBW_REPAIR_WHEEL_COMMAND_MACOS: |
    echo "Target delocate archs: {delocate_archs}"

    ORIGINAL_WHEEL={wheel}

    echo "Running delocate-listdeps to list linked original wheel dependencies"
    delocate-listdeps --all $ORIGINAL_WHEEL

    if [ "${{ matrix.cibuildwheel_platform_id }}" == "macosx_arm64" ];
    then
      echo "Renaming .whl file when architecture is 'macosx_arm64'"
      RENAMED_WHEEL=${ORIGINAL_WHEEL//x86_64/arm64}

      echo "Wheel will be renamed to $RENAMED_WHEEL"
      mv $ORIGINAL_WHEEL $RENAMED_WHEEL
    else
      RENAMED_WHEEL=$ORIGINAL_WHEEL
    fi

    echo "Running delocate-wheel command on $RENAMED_WHEEL"
    delocate-wheel --require-archs {delocate_archs} -w {dest_dir} -v $RENAMED_WHEEL

    echo "Running delocate-listdeps to list linked wheel dependencies"
    WHEEL_SIMPLE_FILENAME="${RENAMED_WHEEL##*/}"
    delocate-listdeps --all {dest_dir}/$WHEEL_SIMPLE_FILENAME

    echo "DONE."

The output is as follows:

Repairing wheel...
  
Target delocate archs: arm64
Running delocate-listdeps to list linked original wheel dependencies
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
/usr/lib/libSystem.B.dylib
/usr/lib/libobjc.A.dylib
Renaming .whl file when architecture is 'macosx_arm64'
Wheel will be renamed to /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-6h5tsf4q/cp310-macosx_arm64/built_wheel/my_project-0.0.1-cp310-cp310-macosx_12_0_arm64.whl
Running delocate-wheel command on /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-6h5tsf4q/cp310-macosx_arm64/built_wheel/my_project-0.0.1-cp310-cp310-macosx_12_0_arm64.whl
Fixing: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-6h5tsf4q/cp310-macosx_arm64/built_wheel/my_project-0.0.1-cp310-cp310-macosx_12_0_arm64.whl
Running delocate-listdeps to list linked wheel dependencies
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
/usr/lib/libSystem.B.dylib
/usr/lib/libobjc.A.dylib
DONE.

The repairing wheel step completed successfully also in this case, and the compiled wheel was successfully installed on Apple M1 and invoked at runtime.

Thoughts? 🙇🏼

[Czaki]

Thanks.
For now I do not know if just link to this response or embed whole script in the documentation.

[azagniotov]

Thanks, @Czaki .

I personally lean towards a more defensive approach and I would just include a link to this discussion where appropriate as oppose to including my code snippet in the official docs.

But, that being said, I defer to you and your team regarding this. Please do what you think is best for the Poetry-based community and such a widely used library (cibuildwheel).

Thank you for your time on this, regardless.

[Czaki]

I have updated the description to be more correct. Did it look better?

[henryiii]

The internal tags will still be broken? You'd need pypa/wheel#422 I believe.

[henryiii]

I'd remove this renaming suggestion and just say the tags have to be corrected. An example is in https://github.com/scikit-build/cmake-python-distributions/blob/master/scripts/repair_wheel.py.

[Czaki]

Now better?

[joerick]

Sorry for the delay on this @Czaki - I'm sorta hoping/waiting til we can get pypa/wheel#422 in so we can give some concrete advice on this, because the file rename advice is imperfect as an approach and has 'gotchas' that make it harder to explain. Hopefully that wheel feature will come soon!

[Czaki]

Lets keep it open until pypa/wheel was released so people can find it if they cannot wait.

[henryiii]

wheel 0.40 is out!

[Czaki]

So could you prepare proper instructions? I'm not on time with wheel. Then I will close this PR.

[henryiii]

If we want it to be done in the cibuildwheel steps (like repair wheel?), we should probably wait until it's in our pinned deps.

[anderssonjohan]

Just wanted to confirm that the wheel tags command seems to do the trick.

Context: We're building python 3.11 wheels of the pendulum package and noticed we got the x86_64 tag for macos arm64 wheels

When adding the opt-in flag to cross-compile for macos arm64 we got the AlreadyBuiltWheelError complaining about the duplicate x86_64 wheel file.

Solution:
Due to the extra steps for the wheel tags command I did a copy-paste and created a separate job to update the tags for the apple silicon wheel like this:
https://gist.github.com/anderssonjohan/49f07e33fc5cb2420515a8ac76dc0c95

[henryiii]

It's in the pinned deps in the latest release, we can update docs now.

[joerick]

I've had a pass on this, including a general improvement to the whole section, comments welcome

[henryiii]

Technically, you can’t build universal natively, not sure what that would mean. I guess emulation for the Intel part then fusing? But that’s okay, not worth changing it (as it can be tested).

[joerick]

Yeah, good point. That statement has been in the docs for a while, but I'll have a think on how to reword that.