On 11/13/24 4:21 AM, David Aguilar wrote: > As to why I consider Python a liability ~ this is more of a concern for > Meson and it doesn't really matter for end users, but Python has a > proven track record of making breaking changes. > > If you're building everything from scratch with new versions of > compilers and tools then the C++ project is the one that's going to > build just fine a decade from now with little to minimal effort. > Python doesn't have that track record. > > Even though CMake is written in C++ (which is unacceptable for some > projects), this is subjectively one advantage that CMake seems to have. > This is a moot point, though, and perhaps Python will eventually reach > this same level of respect for not introducing breaking changes. > > Furthermore, I suspect that most contributors are simply going to > "apt install meson" or "brew install meson" so it's not really that much > of an issue in practice for the majority of users/contributors. For what it's worth, meson is aware that python breaking changes are a potential issue. Although the general python ecosystem is fairly lax about this -- on *all* points across: - cpython itself being backwards incompatible - projects making breaking changes in a micro release - projects deciding to only support the latest, or 2 most recent, versions of cpython meson pedantically avoids non-standard-library dependencies both for bootstrappability and for points 2 & 3. Regarding point 1, meson can't do a lot other than adapt. But the latest version of meson will always support *all* non-EOL versions of python, we do prerelease testing of cpython betas, and we do not drop support even for EOL versions of cpython unless, having carefully evaluated the benefits and negatives, we decide that the advantages of relying on a new version outweigh the downside of preventing people on older systems with older cpython from upgrading meson. Currently that means we still support 7 different versions of cpython, including 2 versions that are EOL (and 4 versions that built with c89, before the migration to c11). Of course, as you say it's a bit of a moot point given that muon exists. But I just wanted to clarify that meson does take this concern seriously and we try to do everything we can to make that work -- even when some meson maintainers are unhappy and feel that being unable to depend on unpredictable third-party modules cramps their style. We know that we are core FOSS infrastructure, and are used by other core FOSS infrastructure projects such as init systems (both systemd and openrc), graphics stacks (mesa, libdrm, both xorg and wayland), desktops (gnome has an official directive to use meson), and a variety of freedesktop projects, many of which need to keep building on LTS versions of Debian oldoldstable (not a typo) and oftentimes on even more surprising platforms. And in some cases we've been a bit influential in getting cpython to revert breaking changes :) e.g. python 3.13 reverted the removal of the importlib.resources "Functional API". -- Eli Schwartz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
