Compiled Python packages distribute pre-built wheels for specific platforms, Python versions, and architectures. This info can be important to know for downstream consumers and contributors but is currently scattered across pyproject.toml, CI configs, and PyPI. So there's no single in-repo source of truth.
The proposal here is to recognize a WHEELS.md convention at the repo root and render it as a page accessible from the package info section of the homepage sidebar. For packages without one, Great Docs could auto-generate a basic version from pyproject.toml metadata (requires-python, classifiers) and [tool.cibuildwheel] config. Packages with more complex build stories (abi3 stable ABI, Pyodide/WASM wheels, skipped platforms) would maintain their own WHEELS.md to document the full picture.
Recently in posit-dev/multimark I added a WHEELS.md that covers native abi3 wheels, Pyodide/emscripten wheels, platform matrix, local build commands, and pre-release testing workflows.
Compiled Python packages distribute pre-built wheels for specific platforms, Python versions, and architectures. This info can be important to know for downstream consumers and contributors but is currently scattered across
pyproject.toml, CI configs, and PyPI. So there's no single in-repo source of truth.The proposal here is to recognize a
WHEELS.mdconvention at the repo root and render it as a page accessible from the package info section of the homepage sidebar. For packages without one, Great Docs could auto-generate a basic version frompyproject.tomlmetadata (requires-python, classifiers) and[tool.cibuildwheel]config. Packages with more complex build stories (abi3 stable ABI, Pyodide/WASM wheels, skipped platforms) would maintain their ownWHEELS.mdto document the full picture.Recently in
posit-dev/multimarkI added aWHEELS.mdthat covers native abi3 wheels, Pyodide/emscripten wheels, platform matrix, local build commands, and pre-release testing workflows.