While working on #28 , I noticed that the python -m build command produces both the Source Distribution and the Built Distribution for the particular platform on which the command is run (e.g. MacOS with Python 3.14 produces planarity-0.7.0-cp314-cp314-macosx_10_15_universal2.whl), unless one uses the --sdist flag to produce only the Source Distribution. Upon further investigation, I notice that only the Source Distribution for planarity is uploaded to PyPI; however, there are some benefits to producing Built Distribution for a matrix of the supported platforms and Python interpreters (see RealPython article "What Are Python Wheels and Why Should You Care?" section Advantages of Python Wheels, as well as the section "Advantages of wheels" on the main Pythonwheels site). It probably goes without saying that doing this manually is infeasible at best and a Very Bad Idea™ at worst.
The GitHub docs on Building and testing Python using GitHub Actions includes a section on Publishing to PyPI, but this only covers pure Python packages which means a universal, platform-independent .whl file is made for the chosen Python version (not a list). Because planarity comprises a Cython extension, we have to produce the Platform Wheel for the matrix of supported platforms, compiler toolchains and their different versions, and Python interpreters, as well as the Source Distribution.
For this we might consider a tool such as cibuildwheel, which has example GitHub Actions.
While we're in the neighbourhood, might as well get about to Adding a workflow status badge to the README.md for the build status.
While working on #28 , I noticed that the
python -m buildcommand produces both the Source Distribution and the Built Distribution for the particular platform on which the command is run (e.g. MacOS with Python 3.14 producesplanarity-0.7.0-cp314-cp314-macosx_10_15_universal2.whl), unless one uses the--sdistflag to produce only the Source Distribution. Upon further investigation, I notice that only the Source Distribution forplanarityis uploaded to PyPI; however, there are some benefits to producing Built Distribution for a matrix of the supported platforms and Python interpreters (see RealPython article "What Are Python Wheels and Why Should You Care?" section Advantages of Python Wheels, as well as the section "Advantages of wheels" on the main Pythonwheels site). It probably goes without saying that doing this manually is infeasible at best and a Very Bad Idea™ at worst.The GitHub docs on Building and testing Python using GitHub Actions includes a section on Publishing to PyPI, but this only covers pure Python packages which means a universal, platform-independent
.whlfile is made for the chosen Python version (not a list). Becauseplanaritycomprises a Cython extension, we have to produce the Platform Wheel for the matrix of supported platforms, compiler toolchains and their different versions, and Python interpreters, as well as the Source Distribution.For this we might consider a tool such as
cibuildwheel, which has example GitHub Actions.While we're in the neighbourhood, might as well get about to Adding a workflow status badge to the
README.mdfor the build status.