Move custom build in setup.py to custom backend in _custom_build

[aclark4life]

Do we need to deprecate setup.py at some point or can it continue to exist indefinitely? Is there any tangible benefit, security or otherwise to move C extension builds to pyproject.toml? Can we assume we'd use the setuptools backend and what's the expected level of effort? I saw #9642 and it made me curious about it.

[wiredfool]

Don't see how that's really possible to do given our level of sniffing for libraries for the build.

[aclark4life]

As it turns out, when there's both a pyproject.toml and a setup.py, pyproject.toml is called first and then we already call out from there to setup.py to build C extensions. So this would be a clean up not a major refactor.

[hugovk]

setup.py itself isn't deprecated, although invoking it directly is. The long version: https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html We stopped invoking directly years ago (in #5896 and linked PRs).

Pure Python projects can usually dispense with setup.py and put static config in setup.cfg (for setuptools projects), or the newer pyproject.toml (for setuptools and a lot more). And already we have all our static config in pyproject.toml.

But we are a setuptools project with C extensions, and setup.py is the natural place to put our build and dependency script. It signals right away that we are using setuptools. It's an old project, but setuptools is fine. There are plenty of other build backends, and especially for pure Python projects you might prefer a more modern one.

I don't mind too much if we move it to a custom build, but I'm fine with it being in setup.py.

---

But we could evaluate moving from setuptools to another build backend that does C extensions. Two that come to mind are meson-python (uses Meson) and scikit-build-standalone (CMake). I don't have experience of either; meson-python is at least used by NumPy, SciPy and pandas. These may have other benefits in addition to dropping setup.py.

[aclark4life]

setup.py itself isn't deprecated, although invoking it directly is. The long version: https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html We stopped invoking directly years ago (in #5896 and linked PRs).

Pure Python projects can usually dispense with setup.py and put static config in setup.cfg (for setuptools projects), or the newer pyproject.toml (for setuptools and a lot more). And already we have all our static config in pyproject.toml.

I'm familiar … but I had forgotten until I started working on this 😄

But we are a setuptools project with C extensions, and setup.py is the natural place to put our build and dependency script. It signals right away that we are using setuptools. It's an old project, but setuptools is fine.

raise Subjective

I don't feel that strongly about it but FWIW that is not my perspective. Setuptools backend with pyproject.toml on new projects is the norm (for me). I don't want to see setup.py hanging around anymore and I'm not confused about the backend still being setuptools.

There are plenty of other build backends, and especially for pure Python projects you might prefer a more modern one.

I don't mind too much if we move it to a custom build, but I'm fine with it being in setup.py.

We're not moving to anything. We have an existing custom backend (subclassing setuptools) and I'm proposing we move the existing custom build in setup.py to the existing custom backend in _custom_build.

But we could evaluate moving from setuptools to another build backend that does C extensions. Two that come to mind are meson-python (uses Meson) and scikit-build-standalone (CMake). I don't have experience of either; meson-python is at least used by NumPy, SciPy and pandas. These may have other benefits in addition to dropping setup.py.

I have experience with scikit-build but there was something about it that didn't fit Pillow, I can't recall at the moment. Anyway, RIP setup.py from me and I find it more confusing to keep the custom build in the "legacy" setup.py. I'd rather see it in _custom_build.

</2cents>