+ notes: 'PR #2178 open (draft, branch certbot-dns-multi). Upstream located by search despite the empty PyPI project_urls: github.com/alexzorin/certbot-dns-multi, MIT, tags are bare version numbers (no `v` prefix); tag 5.4.0 = 3f8d156d97b3e1a243dc1de0c6b30f9c686067b3, which matches the sdist _version.py''s __commit_id__ g3f8d156d9. The cp311-cp314 tags are NOT cosmetic and this is not gotcha 27/464''s fabricated-tag shape: setup.py declares a real Extension("lego_bridge", ["certbot_dns_multi/_internal/bridge/main.go"]) with build_golang, so setuptools-golang builds a genuine CPython extension module out of cgo - certbot_dns_multi/_internal/bridge/main.c holds PyInit_lego_bridge/PyModuleDef and main.go holds the //export lego_bridge_cmd entry that go build -buildmode=c-shared links into it. The 33-36 MB per-wheel payload is the embedded go-acme/lego v5.4.0 provider set plus the Go runtime, and the per-interpreter tags are honest (the .so links against the interpreter''s C API). Feasibility is clean: internal/platform/supported.go lists linux/riscv64 in the c-shared buildmode table, go1.26.0.linux-riscv64.tar.gz exists, setuptools-golang 2.9.0 has no architecture table at all (it only shells out to `go build`), and a GOOS=linux GOARCH=riscv64 CGO_ENABLED=0 cross build of github.com/go-acme/lego/v5/providers/dns - the whole dependency closure the bridge imports - succeeded on x86 in under two minutes, so no Go dependency is arch-gated. build-certbot-dns-multi.yml is build-from-checkout at the tag with cibuildwheel over cp312/cp313/cp314; upstream''s own .github/build-manylinux.py has an arch->image map with only amd64/arm64, so cibuildwheel replaces it while keeping upstream''s recipe (the same go.dev tarball curl that .github/build-wheel.sh does, for GOARCH=riscv64, in CIBW_BEFORE_ALL_LINUX). No cp314t: the Go bridge declares no Py_mod_gil slot, so a free-threaded wheel would silently re-enable the GIL at import, and upstream ships cp311-cp314 only. SETUPTOOLS_SCM_PRETEND_VERSION_FOR_CERTBOT_DNS_MULTI is set because the pyproject reads its version from the setuptools_scm-written _version.py and the git tag is not reliably readable inside the container; the _FOR_ name normalisation was verified locally against the real checkout. CIBW_TEST_ENVIRONMENT pins PIP_ONLY_BINARY=cryptography so the test venv takes our registry''s riscv64 cryptography (50.0.1 cp312-abi3 covers the whole matrix) instead of source-building PyPI''s Rust sdist; certbot itself and the rest of its closure are py3-none-any. No patches needed. Upstream ships no test suite (tests/ holds only an empty __init__.py), so the workflow stages one from a run: heredoc and runs it via CIBW_TEST_SOURCES: it drives the compiled bridge over its JSON protocol - unknown action, unknown provider, a provider whose credentials are missing, and a full configure/perform/cleanup round trip through lego''s `exec` provider in EXEC_MODE=RAW, which takes the branch that skips dns01.GetChallengeInfo and therefore needs no network or DNS at all - then loads the certbot.plugins entry point and asserts it is a dns_common.DNSAuthenticator subclass. Local validation before pushing: the wheel builds on this x86_64 host from the tag (pip wheel, ~4 min) and all 6 staged tests pass against the installed wheel after extracting the heredoc byte-for-byte out of the YAML; a riscv64 rehearsal of the same build ran under docker+QEMU on quay.io/pypa/manylinux_2_39_riscv64 (go1.26.0 linux/riscv64 installs and runs; the cgo compile itself is slow under emulation). Registry check: nothing for certbot, acme or josepy on pypi.riseproject.dev, but all three are py3-none-any on PyPI, so only cryptography/cffi need riscv64 wheels and both are hosted.'
0 commit comments