On 3/18/25 1:02 PM, Rob Herring wrote: >> Meson *is* "the python way", for what it's worth, as it's a genuine > > As a backend, yes it seems so, but I meant as a front-end where users > run pip (or historically setup.py) rather than running ninja to run > pip or setup.py. But looks like with this patch meson works as both > the front-end and back-end. All news to me really, as pretty much > nothing I've read on how to create and/or install python projects > mentions meson, but it's certainly a moving target with setup.py, > setup.cfg, pyproject.toml... It is a bit confusing, but I think that's mostly a PR thing. For a bit of context here: Way back in the old day, setup.py was a second-stage cross platform "basically a Makefile" for cpython itself. The cpython standard library bootstrapped itself far enough to run a script called setup.py which built the rest of the standard library C modules, in part because writing this logic in python meant they didn't have to do it twice, once in a unix makefile and once in a Windows VS solution file. Naturally, shipping "basically a Makefile" in the standard library so you could build the standard library, was an attractive idea to others who wanted to build third-party python modules. Free build system! Runs on Windows without GNU Make! So people used it, and the PyPI ecosystem grew up around it, and setuptools was created to add some extra commands for `setup.py`, especially since not all functionality was needed by the standard library but was needed by third-party modules. Along the way, setup.cfg was invented. It's an ini file that you can use instead of passing most arguments to setup() because it's easier to configure metadata arguments via a config file rather than a python program. "declarative config" is the big appeal. At a certain point they also decided that ini files were too 2010s and wanted to shift to the hot new thing, TOML. (Tom's non-obvious maximalist language) Around the same time, people were feeling a bit let down by this glorious hack of unintended functionality (a stdlib portable Makefile retrofitted as a packaging standard) and especially setuptools was relatively very slow if all you had was pure *.py scripts, so they invented some alternative wheel builders (flit and poetry) and eventually decided to make a formal spec that would allow "pip install" to stop assuming everything is a setup.py Basically, they tried to reinvent linux distro build recipes I guess? So, pyproject.toml fulfills two roles: - it has the metadata-only parts of setup.py, all declarative - it tells pip what the python module contains a "build_wheel" function that knows how to build this particular package For us, that latter one is meson-python. It's a tiny python script that knows how to run the "meson" program, invoke ninja as needed, and tar up the results in a wheel file. All the real work aside for packaging is done by meson. Setuptools, naturally, provides its own "build_wheel" function (and you will no doubt be shocked to learn it executes `python3 setup.py bdist_wheel`). The moving target was years ago. These days the confusion is all about everyone inventing their own "build_wheel" functions now that they are allowed to. Most of them do exactly the same thing as each other, but rewritten from scratch with slightly different spelling (or in some cases their explanation is that they needed to create a new fork because they "need to be able to control the quality of the error messages") rather than rely on existing, proven tools such as meson, autotools, or cmake. It is what it is. For us, meson-python is only just enough of a thin wrapper to convert the results of "meson install" into a wheel file, which is simply format shifting. >> python build system, no wrapper :) -- Eli Schwartz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
