mesonbuild
Move to python 3.10
3.9 EOL: 2025-10-31 (https://endoflife.date/python)
Distro availability:
- Debian oldoldstable (buster) is stuck on 3.7. oldstable (bullseye) has 3.9, stable (bookworm) has 3.11
- RHEL 8 has python 3.6, RHEL 9 has 3.9, RHEL 10 has ???. All have "AppStream" access to 3.12 etc.
- Ubuntu 18.04 has 3.8, Ubuntu 20.04 has 3.8 by default with an upgrade to 3.9, Ubuntu 22.04 has 3.10
- OpenSUSE Leap always has a
python3package owning the default python as 3.6. Leap 15.4 and on, have a "python310" and "python311" package. Leap 15.3 was EOL in January - XCode on macOS: has python 3.9
Useful features that we can take advantage of in development: https://docs.python.org/3/whatsnew/3.10.html
- Structural Pattern Matching. Pretty huge.
- dataclass
__slots__support, I've been looking forward to this for a while - dataclass
KW_ONLY, likewise - importlib.metadata has a guaranteed stable API, relevant for the
import('python')module -
platform.freedesktop_os_release() may be a useful API to offer via
host_machine.
https://repology.org/project/python/versions
https://en.opensuse.org/Lifetime
LTS Linux distros you didn't mention:
- SUSE Linux Enterprise Desktop/Server
- Amazon Linux (AL2, AL2023)
As far as I know, AWS isn't an important stakeholder environment for running meson, so investigating what version of meson can run in an ephemeral on-demand EC2 instance shouldn't be necessary.
SLES follows Leap (SLES 15 SP1 is Leap 15.1 etc). The python3 binary is python 3.6 for backwards compat and it's not clear whether this will ever change (since we need 3.7 anyway, it's obvious that one needs to do something to get meson woking on SUSE). The question is what other versions you can get.
RHEL
- RHEL 8: Python 3.6, AppStream Python 3.11, 3.12
- RHEL 9: Python 3.9, AppStream Python 3.11, 3.12
RHEL and SLES both have multiple runtimes; all except the oldest have only the standard library, and everything else should be installed with pip. Adding to what @amitdo said, SLES 15 also has everything available up to 3.12. Since Meson does not need any dependencies, it can run on RHEL and SLES.
Quoting @dcbaker:
@dcbaker on Mar 4, 2025
... but I'd rather wait on the wholesale rewrite until 3.10 when we also get | for list[str | None] vs T.List[T.Optional[str]], and only rewrite the annotations once.
@dcbaker on Jun 5, 2025
I'd really like to move to 3.10 in October when 3.9 reaches EOL, the switch statement in particular would be pretty nice. so if not before then, in October I'm planning to push for that
Just to be clear, I think bumping to 3.10 will be worthwhile, the list of things that have accumulated or shown up in 3.10 it pretty impressive:
- match statements
- type unions in annotations with
|(ie,str | Noneinstead ofT.Optional[str]) - all of the things we use from typing_extensions will be in typing (ParamSpec, Protocol, TypedDict, Literal, etc)
- standard containers for type annotations
- the walrus operator
- position only parameters
- improvements to dataclasses including slots and keyword only arguments
I think that list is comprehensive enough, and helpful enough to warrant a move to 3.10.
I don't care about typing annotation changes. One of the big claims of type checking is that they don't affect runtime so only mypy cares about them. If it was just about typing annotation changes I wouldn't want to upgrade (and versions before 3.10 would have been interesting already).
But as I said in the starting post: match statements sound exciting, and dataclass improvements are something I've been looking forward to for a while. I also like the idea of positional only parameters -- I'm not entirely sure they're enough on their own but I will certainly be happy to use them once we require a new enough version of python, at least.
Still reserving judgment on the walrus operator. :P The main use case for it appears to be code golfing and I don't love how it looks. I suppose there is probably a subset of cases where it allows you to genuinely do something you couldn't otherwise do. Maybe.
I know you're not sold on it. I don't think it's a panacea, but there are cases I've used it in my own code (outside of Meson, of course) where I think it improves readability or avoids multiple lookups.
My point was (apart from match) there's nothing individually that is super exciting, but the QoL improvements of all of that taken as a whole is pretty convincing to me.
@eli-schwartz, @dcbaker,
If you want to move to Python 3.10 sooner rather than later, you should add this note to the release notes:
This is the last Meson release to support Python versions 3.7, 3.8 and 3.9. The minimum required Python version for the next Meson release will be raised from 3.7 to 3.10.
Python 3.9 reached its EOL on October 31, 2025.
https://devguide.python.org/versions/
If we're going to do this soonish, I'd have a preference to do it for Meson 1.11 rather than 1.10.
Actually this sounds bogus. Cygwin appears to have 3.12 packaged: https://cygwin.com/packages/summary/python312.html
That means cygwin is in the same boat as OpenSUSE. We might care about that as part of why we refuse to drop support until that version of python is EOL, but after the EOL date the argument becomes pretty thin; people can manually install the newer interpreter as long as it's packaged.
(It would be good for cygwin to change their default, for many reasons. Although if they haven't gotten most packages rebuilt yet, what can they do?)
Oh, I was looking at https://cygwin.com/packages/summary/python3-devel.html
(It would be good for cygwin to change their default, for many reasons. Although if they haven't gotten most packages rebuilt yet, what can they do?)
This is in progress, but as always, we are very constrained on resources, so the timescale is uncertain.
This shouldn't hold you back, though.
Just updating the package list in the cygwin.yml workflow to explicitly list python312 etc. should be enough. ('python' is a link managed by alternatives so should automatically point to 3.12 if it's installed)
