Conversation
- Detect Emscripten cross-compilation in setup.py, skipping platform-specific sources (CoreText, DirectWrite, Uniscribe) - Add build-pyodide job to CI workflow - Upload Pyodide wheel to GitHub releases only (PyPI doesn't accept wasm32 wheels yet, see pypi/warehouse#10416) Fixes #270
| define_macros.append(("HAVE_DIRECTWRITE", "1")) | ||
| define_macros.append(("HAVE_UNISCRIBE", "1")) | ||
| libraries += ["usp10", "gdi32", "user32", "rpcrt4", "dwrite"] | ||
| sources += [ |
There was a problem hiding this comment.
I think harfbuzz.cc has all these files automatically included.
There was a problem hiding this comment.
but harfbuzz.cc lacks the subset module..
Pyodide doesn't support Python 3.14 yet, so we need to use 3.13 explicitly instead of '3.x' which resolves to the latest.
Remove redundant test step - cibuildwheel already runs tests via test-command for each wheel it builds.
|
@Vipitis the CI finally built some pyodide wheels for uharfbuzz here: https://github.com/harfbuzz/uharfbuzz/actions/runs/20712353445/artifacts/5023130791 Would you like to give them a go? The uharfuzz own tests do pass when run inside a pyodide venv, like cibuildwheel does. |
|
hey @anthrotype thanks a lot for figuring this out. I obtained the wheel yesterday already from your branch and now also from the ci artifacts. The latter has the wrong version number ( |
|
thanks for checking. the version number is expected, only when we push a tagged commit to do an actual release we do a full clone and "unshallow" the repository so the correnct version string is obtained from git. The 0.1 is setuptools-scm failing to get a proper tag. |
|
Is there anything blocking this? |
|
I was waiting for them to test if these actually work.. the tests pass, so feel free to merge |
|
Uploading the Pyodide wheels seems to fail: https://github.com/harfbuzz/uharfbuzz/actions/runs/23300214344/job/67760947291 |
|
You can't upload to PyPI yet I think, they aren't sufficiently standardised IIRC. I am at a conference right now and can't check, but I believe the path forward for now would be to disable the automatic upload for those and perhaps make them available only as GitHub Release downloadable assets |
|
Oh now I remember I had written about that (see above here)
|
|
Oh! It's the GH assets upload that it's failing (not PyPI), sorry I hadn't read it carefully. Ok not sure. Next thing to check, is the GitHub token used enabled for "write"? |
| - name: Upload Pyodide wheel to GitHub release | ||
| run: | | ||
| if [ -d dist-pyodide ] && [ "$(ls -A dist-pyodide)" ]; then | ||
| gh release upload ${{ github.ref }} dist-pyodide/*.whl |
There was a problem hiding this comment.
@khaledhosny i think the issue is this is supposed to be github.ref_name ("v0.53.4") instead of github.ref ("refs/tags/v0.53.4").
And for consistency also the gh release create call right above this (which somehow normalises ref to ref_name internally, whereas upload command doesn't).
There was a problem hiding this comment.
since we'll have to re-tag, the release that was created will have to be deleted as well
tox -e pyodidefor local build and testFixes #270