dockerfile: Add version 3.4.0

[luhenry]

• Package: dockerfile
• Version: 3.4.0
• Source: https://github.com/asottile/dockerfile
• Docs: https://github.com/asottile/dockerfile

Compiles pylib/main.go via setuptools-golang (go build -buildmode=c-shared) into a CPython limited-API extension wrapping buildkit's Dockerfile parser. Upstream publishes no riscv64 wheel.

Mirrors upstream's main.yml Linux job; upstream builds its Linux wheel by hand with setuptools-golang's manylinux helper.

Differs from upstream

• cibuildwheel instead of setuptools-golang-build-manylinux-wheels - same setup.py path inside the manylinux_2_39_riscv64 image.
• Go 1.26.8 linux-riscv64 tarball (sha256-pinned) installed in before-all - upstream pins no Go version for its Linux wheel.

Matrix: one cp312-abi3 wheel, reused and tested on cp313/cp314. No cp314t: setup.py forces the abi3 tag without a Py_GIL_DISABLED guard, and upstream ships no free-threaded wheel.

Testing

• testfiles/ staged next to tests/ - the suite opens testfiles/Dockerfile.ok by relative path.

License: MIT; the extension statically links buildkit's parser (Apache-2.0) and the Go runtime (BSD-3-Clause), as upstream's own wheel does.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-10-01 18:06 UTC

[luhenry]

Build fails on cp312-abi3 at cibuildwheel's own post-repair abi3audit --strict step (not a build or test failure): it reports "0 ABI version mismatches and 8 ABI violations" against dockerfile.abi3.so, naming PyDockerfile_Heredoc, PyDockerfile_Command, PyDockerfile_NewCommand, PyDockerfile_GoParseError, PyDockerfile_GoIOError, PyDockerfile_NewHeredoc, PyDockerfile_Py_RETURN_NONE, PyDockerfile_PyArg_ParseTuple_U as non_abi3_symbols.

These aren't CPython C-API calls the extension makes - they're //export-marked Go functions from upstream's own pylib/main.go, exposed via go build -buildmode=c-shared. That build mode makes every //export function a globally visible symbol in the resulting .so by design; there's no post-hoc way to hide them without either restructuring upstream's Go source to stop exporting the internal helpers (only the true CPython entry point needs to be public) or dropping cibuildwheel's automatic abi3 audit for this identifier.

Confirmed this is specific to how this port builds it, not upstream's own process: upstream's pyproject.toml/setup.cfg has no [tool.cibuildwheel] section and no abi3audit anywhere - their own CI builds via asottile/workflows' shared tox-based flow, which doesn't run this check at all. So this wall is a property of routing the build through cibuildwheel v4.2.0 with only: cp312-abi3, not a riscv64-specific issue and not something upstream's own recipe would ever hit.

Options, none of which I want to guess-and-burn a ~40min rebuild on without a second opinion:

1. Rework the Go source to stop //export-ing the internal helpers (most correct, touches upstream code we'd need to patch).
2. Build separate non-abi3 wheels per interpreter (cp312/cp313/cp314) instead of one abi3 wheel, sidestepping the audit entirely - straightforward but gives up the one-wheel-fits-all win abi3 was chosen for.
3. Check whether there's a cibuildwheel setting to skip/relax abi3audit for this identifier (haven't found one).

Leaving this parked here rather than pushing a speculative fix.

---

Generated by Claude Code