+ notes: '4 Linux wheels upstream (abi: py3); no riscv64 on PyPI or pypi.riseproject.dev. PORTED - PR https://github.com/riseproject-dev/python-wheels/pull/2177 open (draft), CI green on run 35621970585: iterfzf-1.9.0.67.0-py3-none-manylinux_2_39_riscv64.whl built on the riscv64 runner in 37 s (sha256 952a1bda1d8bb0b567f3b566bbfc9b365bab1f95fb4e3de1594205b6612a3802), all four test legs (3.12/3.13/3.14/3.14t) green with the bundled binary printing 0.67.0 (2ab923f3) on the real runner and 11 passed / 3 deselected each, and the publish job dry-ran clean (would tag iterfzf-v1.9.0.67.0-20260921162444, add iterfzf to packages.txt and open the docs PR). Left as a draft for the maintainer. An earlier head (0652c1c) failed check_commit_messages only because the PR body carried a tool-injected attribution footer at creation time; the body was cleaned and the branch re-pushed (the pull_request payload is not refreshed by editing the body, so a new head commit is the only way to re-run that check). Vendored-prebuilt-binary shape (gotcha 35/500 family) with the opposite verdict to adbutils (gotcha 524): the vendor already publishes our architecture. iterfzf is pure Python around the fzf binary; its PEP 517 backend build_dist.py downloads junegunn/fzf''s own release asset for a (GOOS, GOARCH) pair and renames the wheel from a goos_goarch_platform_tag_map entry, with a parallel platform_machine_goos_goarch_map for native detection. The version string names the release to check - 1.9.0.67.0 is wrapper 1.9 + fzf 0.67.0 - and fzf-0.67.0-linux_riscv64.tar.gz exists; 0.67.0 is the first fzf release carrying it (0.66.0, 0.65.0, 0.60.0, 0.50.0, 0.46.0, 0.44.0, 0.40.0, 0.30.0 all 404 for that asset name), i.e. exactly the release this wrapper pins. Nothing is compiled, so no Go toolchain, no manylinux container and no gpl_sources job (GPL-3.0-or-later covers the pure-Python wrapper, whose source ships in the wheel; the bundled fzf is MIT). Port is one patch adding the riscv64 row to both tables (missing = KeyError: (''linux'', ''riscv64'') with explicit GOOS/GOARCH, RuntimeError: unsupported platform natively, which is also what a user''s pip install from the sdist hits), plus upstream''s own release.yaml line narrowed to riscv64: GOOS=linux GOARCH=riscv64 python -m build --wheel. Tag chosen is manylinux_2_39_riscv64, matching austin-dist''s hand-set tag precedent. Local rehearsal on x86_64 (the build is arch-independent - a download plus a zip): the patched 1.9.0.67.0 checkout built iterfzf-1.9.0.67.0-py3-none-manylinux_2_39_riscv64.whl (1,693,756 bytes) containing iterfzf/fzf, the release json, test_iterfzf.py and dist-info/licenses/LICENSE, no fzf.exe; the bundled binary is byte-identical (sha256 5693efd07c5b3a327f2a0401d4f38c6904e0b9034066a27b4ba4f495c909cc53) to the official asset, whose tarball sha256 9e578fe8ee88f71498a606551b75d70f1bfadae7602e39860e6e2b88367ecbb4 matches fzf_0.67.0_checksums.txt, and it is a statically linked rv64gc double-float Go binary (ELF e_machine 243, no libc, no vendor ISA - gotcha 449 clear). The same tree with GOOS/GOARCH=linux/amd64 reproduces upstream''s own released wheel filename. Testing mirrors upstream''s tox.ini, minus two of its four commands: iterfzf([]) raises AttributeError at this tag on every platform (the subprocess is spawned only on the first item, so stdin stays None), reproduced against upstream''s own published manylinux x86_64 wheel - recorded as gotcha 529. The wheel ships iterfzf/test_iterfzf.py, so the job runs pytest --pyargs iterfzf.test_iterfzf against the installed artifact: 11 passed, 3 deselected (they open the full-screen picker and need an interactive terminal; running them under a pty hangs rather than passes, which is why upstream''s CI runs tox and not this file). Note the backend renames only the wheel filename - dist-info/WHEEL still says Tag: py3-none-any - and both pip and uv install it regardless. Interpreter matrix is the default four; the wheel is interpreter-agnostic, so every leg exercises the same binary. Unvalidated locally: the api.github.com release lookup (this session''s proxy blocks that repo''s API, so the rehearsal seeded the sdist''s cached release json) and the riscv64 runner itself.'
0 commit comments