Skip to content

Add --python-implementation option to generate-ci - #3318

Closed
astravaleheart wants to merge 1 commit into
PyO3:mainfrom
astravaleheart:add-python-implementation-generate-ci
Closed

astravaleheart wants to merge 1 commit into
PyO3:mainfrom
astravaleheart:add-python-implementation-generate-ci

Conversation

@astravaleheart

Copy link
Copy Markdown

Closes #2013.

What

Adds a --python-implementation <cpython|pypy|graalpy> option to maturin generate-ci, defaulting to cpython (no change to existing output). When pypy or graalpy is selected, the generated GitHub Actions workflow:

  • sets up the matching interpreter via actions/setup-python (pypy3.<minor> or graalpy24.2) instead of a CPython version string
  • builds wheels with an explicit -i <interpreter> instead of --find-interpreter (which only matches pythonX.Y-style names and won't discover PyPy/GraalPy binaries)
  • skips the free-threaded wheel build step, since free-threading is CPython-specific
  • omits the Windows architecture matrix input, since PyPy/GraalPy don't ship prebuilt Windows arm64 interpreters

Why

Issue #2013 asks for a CLI option to select the target Python implementation for generate-ci, since today the generated workflow only knows how to set up and target CPython. This closes that gap for the two implementations PyO3 itself already supports (PyPy via PyO3/pyo3#393, GraalPy via PyO3/pyo3#3247).

How tested

  • cargo test --lib: 273 passed, 0 failed, including 3 new tests covering the PyPy/GraalPy code paths; all pre-existing generate-ci snapshot tests pass unmodified, confirming the cpython default is unaffected
  • cargo fmt --all -- --check and cargo clippy --tests --all-features -- -D warnings: both clean
  • Manually generated a full workflow (maturin generate-ci github --python-implementation pypy -m test-crates/pyo3-pure/Cargo.toml) and reviewed the YAML output across all platform jobs

Known limitation

The default Windows target list still includes aarch64, which has no PyPy/GraalPy build available. This is user-fixable today via the existing [tool.maturin.generate-ci.github.windows] targets = [...] pyproject.toml override; teaching generate-ci to auto-filter targets per implementation would be a separate follow-up and is out of scope here.

maturin.schema.json is intentionally unchanged -- this is a CLI-only flag (like --skip-attestation), not a pyproject.toml config key.

Closes PyO3#2013. maturin generate-ci github only ever set up CPython via
actions/setup-python and built wheels with --find-interpreter, which
doesn't discover PyPy or GraalPy executables (they aren't named
pythonX.Y). Add --python-implementation <cpython|pypy|graalpy>
(default cpython, so existing output is unchanged) that selects the
matching actions/setup-python python-version value and passes an
explicit -i <interpreter> to maturin build instead of
--find-interpreter.

When a non-CPython implementation is selected, the free-threaded
build step is skipped (free-threading is a CPython-specific ABI
concept) and the Windows architecture matrix input is omitted, since
PyPy/GraalPy don't publish prebuilt arm64 Windows interpreters; users
who need to change targets per-implementation can still do so via the
existing [tool.maturin.generate-ci.github.<platform>] targets
override in pyproject.toml.
@astravaleheart

Copy link
Copy Markdown
Author

Apologies — this PR was opened by an automated system under test that acted outside its intended approval gate. Withdrawing it; sorry for the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add pypy and maybe graalpy support to generate-ci

2 participants