pyicu-binary: add build-pyicu-binary.yml for riscv64 wheels - #1508
Merged
Conversation
luhenry
force-pushed
the
pyicu-binary
branch
from
September 8, 2026 06:14
2d558e0 to
9f1cff9
Compare
Drives cibuildwheel directly against a checkout of gitlab.pyicu.org/main/pyicu (published to PyPI as PyICU-binary), which carries no wheel-build CI of its own. libicu-devel 74.2 is available in the manylinux_2_39_riscv64 image's appstream repo, so the extension links dynamically against system ICU the same way setup.py's icu-config/pkg-config probing already expects; auditwheel then vendors the linked libicudata/libicuuc/libicui18n into the wheel, which is the whole point of the "-binary" name. Two patches. The git tree itself always names the project "PyICU" (the "-binary" rename is done outside this tree when whoever publishes the actual PyPI project builds it), so setup.py needs the same rename or the wheel's own METADATA reports the wrong package name and _publish-wheel.yml would register/publish it as "pyicu" instead. 2.7.4 also predates CPython 3.12's removal of the legacy PyUnicode_WCHAR_KIND enumerator, so building common.cpp against a 3.12+ header fails; backports the same #if gate upstream shipped two releases later (v2.11, commit 8850cfca5aeaf040170edca6796002feff0eb82c). Verified locally end to end: built the patched tree against a from-source ICU4C 74.2 (matching what the manylinux image ships) on Python 3.12 and ran its own test suite - 69 passed, 4 deselected. Those four assert CLDR- formatted strings and a tzdata transition pinned to ICU <=69 (the test file's own version check tops out at "68.0"); ICU 74.2's newer CLDR/tzdata data legitimately renders them differently, unrelated to riscv64 or this patch.
luhenry
force-pushed
the
pyicu-binary
branch
from
September 8, 2026 08:51
9f1cff9 to
0da0e2e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pyicu-binary2.7.4Compiles PyICU's C++ extension against system ICU and lets auditwheel vendor libicudata/libicuuc/libicui18n into a self-contained wheel. Upstream publishes no riscv64 wheel and carries no wheel-build CI of its own to mirror.
Differs from upstream
dnf install libicu-develinCIBW_BEFORE_ALL_LINUX- upstream has no CI recipe to inherit/usr/share/licenses/libicu/LICENSEinto the wheel - required once ICU is vendored inTesting
test/suite via pytest, staged withCIBW_TEST_SOURCESLicense: Wheel bundles ICU (Unicode License) via auditwheel; its notice ships as
LICENSE.icusince upstream carries none for it.Patches
0001-common-gate-the-deprecated-PyUnicode_WCHAR_KIND-cas.patch- Backport [gitlab.pyicu.org/main/pyicu@8850cfc, released in v2.11]. CPython 3.12 removedPyUnicode_WCHAR_KIND, which 2.7.4 still switches on unconditionally; reproduces on any host, not riscv64-specific.Built and tested on cp312 against a from-source ICU4C 74.2 (matching the manylinux image): 69 passed, 4 deselected.