parity_venv.sh follows the app to 3.13; the abi3 tag stays at cp312

The wheel is cp312-abi3, so it loads on 3.13 unchanged — the pin that has to
move is the interpreter the parity venv is built with, since its whole point is
resembling what the image ships.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CDYRXGB8tW4NE7b91g7Kdb
This commit is contained in:
2026-08-11 07:24:08 +02:00
parent 6b8a79ba36
commit fab8e93a4b
3 changed files with 17 additions and 12 deletions

View File

@@ -151,9 +151,11 @@ dlopen. One `.cpp` per module keeps incremental compiles cheap — only the link
is shared.
**abi3 (`cp312-abi3`)** from the first build, matching forge/assay, so the
Python 3.13 bump (roadmap 10D) needs no rebuild. Escape hatch if a nanobind
STABLE_ABI limitation ever bites: drop `STABLE_ABI` and `wheel.py-api`, since
every deployed environment is 3.12. Stub generation works fine under abi3.
Python 3.13 bump (roadmap 10D) needed no rebuild — the same wheel loads on the
3.13 the app now ships. The tag stays at `cp312`: it is a floor, and raising it
would buy nothing. Escape hatch if a nanobind STABLE_ABI limitation ever bites:
drop `STABLE_ABI` and `wheel.py-api`, since every deployed environment is on one
interpreter. Stub generation works fine under abi3.
**Version `<occt>.N`**, asserted at configure time against the OCCT actually
found, so `occt_version()` keeps reporting the truth for assay's goldens.