Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update wgpu-native version #445

Merged
merged 2 commits into from
Dec 6, 2023
Merged

update wgpu-native version #445

merged 2 commits into from
Dec 6, 2023

Conversation

dskkato
Copy link
Contributor

@dskkato dskkato commented Dec 6, 2023

This is a follow-up to the 0.18.1.3 release of wgpu-native. See gfx-rs/wgpu-native#326 (comment)

Changes

  • update wgpu-native version from 0.18.1.2 to 0.18.1.3
  • use "aarch64" for mac and linux instead of arm/arm64

Verified to work on Raspberry Pi OS (64-bit).

Resolves #187.

- from 0.18.1.2 to 0.18.1.3
- use "aarch64" for mac and linux instead of arm/arm64
@dskkato dskkato requested a review from Korijn as a code owner December 6, 2023 05:57
@Korijn
Copy link
Collaborator

Korijn commented Dec 6, 2023

Macos ARM is apple Silicon right? We don't want to drop support for apple Silicon?

@dskkato
Copy link
Contributor Author

dskkato commented Dec 6, 2023

@Korijn I do not intend to discontinue the support for Apple Silicon's macOS, simply a follow-up to the wgpu-native binary name change. See this comment : gfx-rs/wgpu-native#326 (comment)

But, I do not have Apple Silicon's macOS on hand, so I cannot confirm if this is causing any problems. If it is causing problems, could you please let me know?

@almarklein
Copy link
Member

Also see https://github.com/gfx-rs/wgpu-native/releases, where one can see the new names.

We should also update the CI so the Linux arm wheels are also created.

@Korijn
Copy link
Collaborator

Korijn commented Dec 6, 2023

I was mostly confused because the python platform tag for the .whl file is officially arm64 on macos. Can you confirm that the proper binary is included in the arm64 .whl file in the build artifacts on this PR?

@almarklein
Copy link
Member

Can you confirm that the proper binary is included in the arm64 .whl file in the build artifacts on this PR?

I just confirmed.

The renaming of "arm64" to "aarch64" only affects the zipfile that is downloaded from the wgpu-native release page. The library is just called "libwgpu_native-release.dylib", so the wheel building is not affected at all by the new name of the zipfile.

@Korijn
Copy link
Collaborator

Korijn commented Dec 6, 2023

OK, then the only remaining work for this PR is what almar mentioned earlier:

  • We should also update the CI so the Linux arm wheels are also created.

So that entails modifying the release-builds job in ci.yml

@Korijn Korijn merged commit 4a24937 into pygfx:main Dec 6, 2023
20 checks passed
@Korijn
Copy link
Collaborator

Korijn commented Dec 6, 2023

Nice one! 🚀

@dskkato
Copy link
Contributor Author

dskkato commented Dec 6, 2023

I added the qemu-release-builds job because the aarch64 build necessitates QEMU. Additionally, Twine checks need to be disabled.

You can check the build artifacts here https://github.com/dskkato/wgpu-py/releases/tag/v0.13.1 .

(though this PR was merged before I could finish writing this description.)

@dskkato
Copy link
Contributor Author

dskkato commented Dec 6, 2023

Thank you for your quick review.

@dskkato dskkato deleted the update_wgpu_native branch December 6, 2023 13:11
@Korijn
Copy link
Collaborator

Korijn commented Dec 6, 2023

I added the qemu-release-builds job because the aarch64 build necessitates QEMU.

Yeah that makes sense!

Additionally, Twine checks need to be disabled.

Why is that? I didn't notice you left that out.

@dskkato
Copy link
Contributor Author

dskkato commented Dec 6, 2023

It's because the built wheel is for aarch64 but twine runs on the host x86_64 env. Perhaps I should have installed twine inside the aarch64 docker container so that we could check the artifact.

@Korijn
Copy link
Collaborator

Korijn commented Dec 6, 2023

Twine check is used to verify the metadata such as the long description (readme on pypi). I don't expect any differences between platforms for that, so I think it's fine like this. 👍

@dskkato
Copy link
Contributor Author

dskkato commented Dec 6, 2023

Oops, I was mistaken about twine not working for aarch64 artifacts, I just thought it was another error I encountered while debugging the CI build.

@almarklein
Copy link
Member

Just pushed a new release, so the new binary wheels are available via pip!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for Raspberry Pi (and other linux_arm64)
3 participants