CI: stop recompiling pyo3 on every run (pin PYO3_CONFIG_FILE in tests sessions)

[alex]

What

In the tests* nox sessions, resolve the PyO3 build config once — against the session venv's interpreter, whose path is stable from run to run — and pin it via PYO3_CONFIG_FILE for the build of cryptography itself. Build isolation stays fully enabled. Bumps the shared rust cache key so caches get re-saved with the new fingerprints.

(Earlier revision of this PR used --no-build-isolation; reworked per review feedback.)

Why

CI logs show every run recompiles pyo3-build-config, pyo3-ffi, pyo3, pyo3-macros-backend, and pyo3-macros (and on Windows, openssl-sys/openssl too) despite a rust-cache hit — e.g. this main run.

Mechanism: PEP 517 builds run in a randomly-named temporary environment (~/.cache/uv/builds-v0/.tmpXXXX), and maturin points PyO3 at that environment's interpreter via PYO3_PYTHON. PyO3's build scripts emit cargo:rerun-if-env-changed for the env vars they actually consult, and the resolved config embeds the interpreter path — so a different temp path every run dirties the whole chain.

PYO3_CONFIG_FILE takes priority over PYO3_PYTHON: when it's set, PyO3 never consults (and therefore never fingerprints) the volatile variables. We generate the config using pyo3's own discovery (PYO3_PRINT_CONFIG=1 against the session interpreter), so it's correct across CPython/PyPy/free-threaded/Windows without hand-rolling sysconfig logic.

Three details to make this work:

• the config file's name is content-addressed — a genuinely different config changes the PYO3_CONFIG_FILE value and correctly triggers a rebuild;
• its mtime is pinned — a regenerated-but-identical file (every fresh CI run) doesn't trip cargo:rerun-if-changed, which compares mtimes;
• ext_suffix and abiflags are appended: maturin also reads PYO3_CONFIG_FILE as the authoritative target description — it requires ext_suffix on Windows and uses abiflags for the wheel tag (without it, free-threaded wheels get tagged cp314 instead of cp314t and the installer rejects them). PyO3 ignores unknown config keys with a warning, so appending both is safe.

Verified locally

With a warm target/, removing .nox entirely and re-running nox -e tests-nocoverage --install-only:

• before: Compiling pyo3-build-config / pyo3-ffi / pyo3-macros-backend / pyo3 / pyo3-macros + workspace crates, every time
• after: Finished release [optimized] target(s) in 0.04s — zero recompiles

Also verified that churning PYO3_PYTHON/VIRTUAL_ENV across fake temp envs with PYO3_CONFIG_FILE set recompiles nothing in the pyo3 chain.

Expected CI impact

Same as measured for the previous revision of this PR (warm run vs baseline): windows build step 1m48s → ~1m04s, the critical-path windows (3.9, tests-nocoverage) job 6.4m → ~4.1m; linux saves the CPU of the pyo3 chain. The first run on each revision is cold (key bump); the following push demonstrates warm behavior.

Behavior notes

• Generation runs via session.run_install, so it executes during nox --install-only (CI's "create env" step) and is skipped under --no-install (CI's "tests" step, where the build already exists).
• The PYO3_PRINT_CONFIG cargo invocation is the documented mechanism for producing config files and costs a few seconds (cached dev-profile artifacts).
• nox -e flake passes locally.

https://claude.ai/code/session_014StKTjk7GBcVdiWKimEsQb

---

Generated by Claude Code

[alex]

Closing in favor of the upstream fix: maturin will export a PYO3_BASE_PYTHON pointing at the stable base interpreter path, and pyo3-build-config will prefer it when resolving the interpreter config — giving stable cargo fingerprints under PEP 517 build isolation without any downstream workarounds. The diagnosis and measurements in this PR (and the maturin PYO3_CONFIG_FILE edge cases it surfaced: ext_suffix required on Windows, abiflags driving the free-threaded wheel tag, PYO3_PYTHON not exported when a config file is present) fed into that design.

---

Generated by Claude Code