Add support for CPython 3.15 (cpy315) and PyPy 8.0 (pypy312, pp80 ABI)

Start with justfile _get-spec and confirm the PyPy 8.0 interpreter version and wheel tags before changing the environment matrix. Then check dependency wheel coverage, the named workflow files, and hatch_build.py for the new targets. Done means both builds produce correctly tagged NVX wheels on the listed platforms, tests and conformance checks run, and the release fileset check and wheel inventory cover the new wheels.

Goal

Two new interpreters in the build, test and release matrix:

• cpy315: CPython 3.15. Not released yet. The current pre-release is
  3.15.0rc3 (2026-10-02), the final
  planned release candidate; 3.15.0 final is scheduled for 2026-10-09.
• pypy312: PyPy 8.0, officially released
  (release post), with the new pp80 ABI.
  PyPy 7.3.x (pp73) was the previous ABI line.

PyPy is a first-class, must-support runtime for autobahn, so pypy312 is the more important of the
two. CPython 3.15 is the easier one, and can go into CI and published wheels now (see below).

So the new suupported venvs table will look like:

• cpy315 => cpython-3.15
• cpy314 => cpython-3.14
• cpy313 => cpython-3.13
• cpy312 => cpython-3.12
• cpy311 => cpython-3.11
• pypy312 => pypy-3.12
• pypy311 => pypy-3.11

CPython 3.15: what the 3.15.0rc3 release notes say

• The ABI is frozen: "There will be no ABI changes from this point forward in the 3.15 series",
  and "Any binary wheels built against Python 3.15.0 release candidates will work with future
  versions of Python 3.15."
• They ask projects to ship wheels now: "We strongly encourage maintainers of third-party
  Python projects to prepare their projects for 3.15 during this phase, and publish Python 3.15
  wheels on PyPI to be ready for the final release of 3.15.0".
• Changes that can touch autobahn:
  • PEP 686: UTF-8 is now the default encoding. Any open() without encoding= changes behaviour
    on platforms whose locale encoding was not UTF-8 (Windows).
  • PEP 803 / 820 / 793: a stable ABI for free-threaded builds. This is the abi3t tag that
    cryptography 50.0.2 already ships. Relevant to #1875 (free-threaded wheels), not needed for
    cpy315 itself.
  • The official macOS installers now install free-threading support by default. uv's interpreters
    are not those installers, and _check-venv-abi already refuses a GIL/free-threaded mix-up, but
    worth knowing when someone builds with a python.org interpreter on macOS.

What we know already

• uv can install both: CPython 3.15.0rc3 since uv 0.12.23, PyPy 3.11.16 and 3.12.14 since
  uv 0.12.19.

• The current PyPy pin in _get-spec is pypy-3.11.15 = PyPy 7.3.23, "last pp73 ABI; pinned
  on purpose (PyPy 8.0 = new pp80 ABI)".

• cryptography (a base dependency since #1947, Rust/pyo3, no pure-Python fallback) already
  ships wheels for both new targets, but not everywhere. cryptography 50.0.2 on PyPI:

  • CPython 3.15: cp315-abi3.abi3t wheels for manylinux (x86_64, aarch64, ppc64le, armv7l),
    musllinux, macOS arm64 and win_amd64.
  • PyPy: pp311-pypy311_pp80 wheels for win_amd64 and macOS arm64 only. Linux PyPy wheels are
    still pp311-pypy311_pp73, and there are no pypy312 wheels at all.

  So today a pypy312 interpreter has to build cryptography from source (Rust plus a native
  OpenSSL) on every platform. That is the same failure mode as #1960, where the Windows wheel job
  broke on a source build.

To confirm first (from the release notes; not reachable from our build host)

• Which Python versions PyPy 8.0 implements (3.11 and 3.12?), and the exact uv specs:
  is pypy-3.11.16 PyPy 8.0, i.e. pp80?
• PyPy 8.0's wheel tags and extension suffix, e.g. pp312-pypy312_pp80, .pypy312-pp80-...so.

Work, starting from justfile _get-spec

1. justfile

   • _get-spec: add cpy315 (cpython-3.15{{PY_PLATFORM_SUFFIX}}) and pypy312 (an exact
     PyPy 8.0 spec, pinned like pypy311, with a comment on the ABI).
   • ENVS: add both. Windows ARM64 stays CPython-only (PyPy publishes no ARM64 Windows
     interpreter).
   • _check-venv-abi: nothing needed for PyPy (skipped); cpy315 is a GIL build, so the existing
     rule applies. Free-threaded cpy315t is out of scope here, see #1875.

2. Dependencies per new interpreter. Check that every base and [all] dependency installs from
   a wheel, or has a pure-Python fallback, on cp315 and pp312/pp80, on Linux x86_64 / aarch64,
   macOS arm64 and Windows x86_64:

   • cryptography, cffi, ujson, msgpack (CPython) / u-msgpack-python (PyPy);
   • cbor2: CPython >=6.1 is Rust-only; PyPy is pinned to ==5.9.0. Check that the pin still
     installs on PyPy 3.12;
   • PyNaCl, zope.interface, brotli / brotlicffi, bjdata (CPython only).

   Anything that needs a source build gets an explicit decision (build it in CI, wait for upstream
   wheels, or leave that interpreter out on that platform), not a silent compile. Note:
   install-build-tools now uses pip install --prefer-binary (#1960), which picks an older
   version with a wheel when one exists. With no wheel at all (cryptography on pypy312 today) it
   still compiles.

3. Workflows: every place that names interpreters explicitly.

   • wheels.yml: via ENVS / build-all.
   • wheels-docker.yml: build_envs: "cpy311 cpy312 cpy313 cpy314", explicit, without PyPy (#1877).
   • wheels-arm64.yml: one matrix entry per version and libc.
   • release.yml: artifact names per version (e.g. artifact_arm64_cp314).
   • main.yml: Import Smoke Test and SerDes matrices; cpy314 is used for quality and coverage.
   • wstest.yml: the cpy314 / pypy311 clients and servers.

4. NVX native extension (hatch_build.py): build and load the CFFI extension on both. The PyPy
   extension suffix changes with pp80, so check that the suffix handling does not assume pp73.

5. Release fileset check (.cicd/actions/check-release-fileset, in wamp-proto/wamp-cicd): it
   parses targets like pypy311-... and wheel tags like pp311-pypy311_pp73. Confirm it accepts
   pypy312 / pypy312_pp80 and cp315. If not, that needs a wamp-cicd issue, since zlmdb and the
   other packages share the check.

6. Metadata and docs: the Programming Language :: Python :: 3.15 classifier (with the first
   release that ships cp315 wheels); docs/wheels-inventory.rst (new wheel names); changelog.

7. PEP 686 (UTF-8 default): look for open() / read_text() / write_text() without an
   explicit encoding= in src/autobahn, and make them explicit, so behaviour does not change
   between 3.14 and 3.15 on Windows. A grep finds nine text-mode open() calls without it:

   • nvx/_xormasker.py:79, nvx/_utf8validator.py:81: read the C sources at build time;
   • wamp/cryptosign.py:284, :300, :331: read signature / public-key files;
   • util.py:944 (/var/lib/dbus/machine-id), util.py:1029 (writes a file), util.py:1063
     (reads a key file);
   • twisted/component.py:168: reads a PEM trust root.

Staging

• pypy312: CI and published wheels as soon as the dependencies install without source builds,
  or with a source build we deliberately accept.
• cpy315: CI now, and wheels for the next release built on 3.15.0rc3 or, from 2026-10-09, on
  3.15.0 final. Per the release notes, RC-built wheels work with the final release, and python.org
  asks for them to be on PyPI before final. The 3.15 classifier goes in with the first release
  that ships cp315 wheels.
• pypy311 (pp73) stays as it is. Dropping it, or moving it to pp80, is a separate decision; Linux
  has no pp80 cryptography wheels yet (#1960).

Acceptance

• just build cpy315 and just build pypy312 produce NVX wheels with the expected tags on
  Linux x86_64 / aarch64, macOS arm64 and Windows x86_64.
• The test suites (Twisted and asyncio), the import smoke tests and WebSocket conformance run on
  both.
• The release fileset check covers the new wheels; docs/wheels-inventory.rst lists them.
• Every dependency that needs a source build on a new interpreter is listed in this issue with
  the decision taken.

Note: This issue was drafted with AI assistance (Claude Code).