Hi, I'm opening this pull request as part of a push to modernise how packages use Flit as a Python build backend.
Using flit_core as the backend in place of flit is recommended in the docs, and will make it faster for tools like pip & build to build your package from source, as it has fewer dependencies to install.
Specifying an explicit version range (>=2,<4) helps to ensure that your package can still be readily built from source despite changes in future major versions of Flit, because it will still use version 3.x. For instance, a future version is likely to drop support for the [tool.flit.metadata] table, in favour of the now-standardised [project] table for metadata. This is also in the docs, along with details of which versions support which features.
Most users probably install your package from a pre-built 'wheel' on PyPI, so this changes won't affect them at all. But people who install from a git checkout, for instance, will benefit.
IamPhytan
commented
8 months ago
Hi, I'm opening this pull request as part of a push to modernise how packages use Flit as a Python build backend.
Using
flit_coreas the backend in place offlitis recommended in the docs, and will make it faster for tools like pip & build to build your package from source, as it has fewer dependencies to install.Specifying an explicit version range (
>=2,<4) helps to ensure that your package can still be readily built from source despite changes in future major versions of Flit, because it will still use version 3.x. For instance, a future version is likely to drop support for the[tool.flit.metadata]table, in favour of the now-standardised[project]table for metadata. This is also in the docs, along with details of which versions support which features.Most users probably install your package from a pre-built 'wheel' on PyPI, so this changes won't affect them at all. But people who install from a git checkout, for instance, will benefit.