Re: What's our minimum supported Python version? - Mailing list pgsql-hackers
From | Jelte Fennema-Nio |
---|---|
Subject | Re: What's our minimum supported Python version? |
Date | |
Msg-id | CAGECzQT5gMntZwTmFQo4=3nFW3V3DeZzuA9575oWZUUV+YNWSA@mail.gmail.com Whole thread Raw |
In response to | Re: What's our minimum supported Python version? (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: What's our minimum supported Python version?
Re: What's our minimum supported Python version? Re: What's our minimum supported Python version? |
List | pgsql-hackers |
tl;dr I think requiring support of Python 3.9 for PG18 would probably be reasonable and save us a bunch of maintenance burden over the next 5 years. On Tue, 22 Apr 2025 at 21:41, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Yeah, that. The distros that are still shipping older Pythons > are LTS distros where part of the deal is that the vendor > is supposed to back-patch security fixes, even if the upstream > has moved on. Maybe a particular vendor is falling down on that > job, but it's not for us to rate their performance. So I don't > buy that "but security!" is a good argument here. I totally agree that "security" is not the discussion that we should be having here. I think the Python version decision (or really any minimum version decision) should be based on some analysis of costs to us for maintaining support vs benefits to the users. I'm pretty sure most users of RHEL expect most modern software not to compile/work completely effortlessly on their distros without some effort on their part or on the part of RHEL packagers. That's kinda what you're signing up for if you choose a distro like that. It might very well be that supporting Python 3.6 does not require many code changes. But it's so old that installing it on most of the recent OSes is not trivial, e.g. uv does not support installing it[1]. By saying we support it, it means that all developers need to go through serious hoops to be able to test that their python scripts work correctly on their own machines. And given our own support policy, we'd probably have to do that for 5 more years (unless we want to change supported python versions in minor PG releases, which I highly doubt we want). So that leaves the question, how much are we actually helping users by spending all that effort on keeping support for old Python versions? Based on the Red Hat docs, it's pretty easy to install newer Python3 versions on RHEL8. Depending on the X in RHEL 8.X you can install different Python3 versions from the official repos[2]. And based on the official RHEL EOL policy[3], only RHEL 8.4, 8.6, 8.8 and 8.10 are still getting some level of support. With 8.4 and 8.6 only getting the final level of support called "Update Services for SAP Solutions", and with 8.8 reaching that same final support level before PG18 is released (and 8.4 becoming unsupported before PG18). Based on that information (only taking into account only RHEL8, not other distros). It seems like we could at least bump the minimum Python support to Python 3.9, which is the newest python that's installable in RHEL 8.4 and 8.6. Anyone that's running a RHEL version that's still supported by Red Hat can then simply do "yum install python39" and run the tests (assuming we set up meson/autoconf to correctly detect the "python3.9" binary). I'd even be curious how much resistance we'd get from RHEL users if we'd bump the Python requirement for PG18 to Python 3.12, which is the newest version that RHEL 8.10 supports. RHEL 8.10 is the only RHEL 8 version that is getting regular support from Red Hat. (Full disclosure: I've used close to EOL versions of RHEL7 professionally, and I hated every second it. I constantly felt like I was walking through a software museum. Having to work around bugs that had been fixed for ages in upstream) Looking a little further than RHEL: - Ubuntu 20.04 can easily install Python3.9 from the official package repos. Currently this is still supported by Cristoph his pgdg repos, but looks like that support might be removed before PG18 given it's transition to "Expanded Security Maintenance" next month. - Ubuntu 22.04 can easily install Python3.11 from the official package repos. Still has full upstream support for 2 years. - Debian Bullseye (EOL in 1.5 years) can only install Python3.9 from the official package repos. - Debian Bookworm (EOL in 3 years) has Pytho - Python 3.8 itself is declared EOL by upstream - Python 3.10 will be declared EOL by upstream around the release of PG19 Based on all this info, I think that it sounds quite reasonable to start requiring Python3.9 for PG18. And for PG19 we could probably start requiring Python3.11 [1]: https://github.com/astral-sh/uv/issues/9833 [2]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/installing-and-using-dynamic-programming-languages_configuring-basic-system-settings#assembly_installing-and-using-python_installing-and-using-dynamic-programming-languages [3]: https://access.redhat.com/support/policy/updates/errata#RHEL8_Planning_Guide P.S. I CC-ed Devrim and Christoph, for insights into this from the packagers perspective.
pgsql-hackers by date: