-
Notifications
You must be signed in to change notification settings - Fork 53
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
Building with pyodide / emscripten on a mac produces bad wheel name (xxx-0.0.1-cp312-cp312-macosx_15_0_arm64.whl) #920
Comments
What about if you run in
Could you also print out all of the variables you find after running This might also need support from upstream CMake to detect it ( |
I agree, this is quite a complex stack of technologies (python, C++, cmake, pyodide, scikit-build-core).
I guess this is part of the pyodide build system, which copies the emscripten compiler.
Here are the relevant cmake variables after find_package(Python)
This is a part where I must admit that I don't know.
I have not explored using cibuildwheel together with pyodide. I think it might be very useful for the CI. |
Afaiu pyodide compiles to the browser's code (WebAssembly?) so it would be architecture and OS independent as long as you have the pyodide environment to run them locally. The scope of pyodide seems to be to make self-contained web applications using python, e.g. interactive jupyter notebooks or the whole holoviews widget ecosystem. @henryiii has more knowledge on this backend.
Try also to see what |
This should work, and I know it does in cibuildwheel. FYI, cibuildwheel is fine to use locally. Ignore the "ci" in the name. :) The binary you produce is in WASM, so the arch doesn't matter. That's one of the key features of WASM, it is the arch, and works on all system arches and platforms. Some tools even use this so they only have to ship one binary (though IIRC it's much easier for that use case to use WASI instead of Emscripten). Also, pyodide's macOS building support is very limited and has several caveats. It's usually better to build in a docker container. |
Hello
I'm trying to build a pyodide package using scikit-build-core, under macOS (ARM M1).
My issue is that the wheel that is produced is indeed a wasm wheel, but it is named "cp312-cp312-macosx_15_0_arm64.whl".
I know that this kind of issue is tricky because it is mixed in between pyodide and scikit-build-core. Anyhow I'd be interested in if a solution is possible.
Steps to reproduce
In order to reproduce the issue you can use the attached archive:
daftsk.tgz
Simply extract it into pyodide/packages, then build it on a Mac with:
Here is a the archive content, which build a simple hello_world function that is bound to python:
here is pyproject.toml
and CMakeLists.txt:
The wheel name is not ok, but its content is actually a wasm module:
Build logs
The build logs are attached in the archive. It ends with "*** Created daftsk-0.0.1-cp312-cp312-macosx_15_0_arm64.whl"
Below is a complete log (except for the final pyodide python exception), with
logging.level = "DEBUG"
Many thanks in advance!
The text was updated successfully, but these errors were encountered: