Re: What's our minimum supported Python version?

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: What's our minimum supported Python version?
Дата
Msg-id 5391e576-d44c-4d02-80ea-a50b8047ce75@eisentraut.org
обсуждение исходный текст
Ответ на Re: What's our minimum supported Python version?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: What's our minimum supported Python version?
Список pgsql-hackers
On 22.04.25 18:04, Tom Lane wrote:
> Jacob Champion <jacob.champion@enterprisedb.com> writes:
>> As for picking a version... 3.6 will have been EOL for almost three
>> years by the time 18 releases. It seems like we would drop it happily,
>> were it not for RHEL8.
> 
> Agreed, but RHEL8 is out there and I don't think we can just drop
> support for it.  I'm also not excited by the idea that an incidental
> test script gets to dictate what the cutoff is.
> 
> I do think we should stop claiming that Python 3.2 will work.
> (Maybe it does, but we don't know that.)  I see that the configure
> script only checks for Python >= 3, and it doesn't look like the
> meson scripts check explicitly at all, although there's a comment
> saying that our meson version cutoff is intended to allow working
> with Python 3.5.
> 
> Maybe it's sufficient to make a documentation change here, and
> say we support Python >= 3.5?  I'd be okay with saying 3.6.8
> too, on the grounds that if anything older fails to work we'd
> almost certainly just say "too bad".  But RHEL8 is widespread
> enough that I think we need to keep making the effort for 3.6.8.

There are a lot of different things that are meant by Python support 
nowadays.

It used to be the case that the minimum Python version was (1) the 
oldest version that was required to get plpython to compile, and (2) the 
range of versions for which we would maintain "expected" files for the 
plpython tests (see history of src/pl/plpython/expected/README).

#2 isn't really a problem anymore, it seems.  It used to require yearly 
attention, but not anymore.  (Maybe Python itself has gotten more 
stable, or we have changed our tests to be less sensitive to this, 
probably a combination of both.)

#1 is also less of a hot-spot, as indicated that we still claim to 
support back to Python 3.2.  Also, starting in PG18, we are using the 
Python "Limited API", so this is being enforced on the Python side. 
That means, in principle, if plpython compiles successfully right now on 
Python 3.13, then it should also compile successfully on Python 3.2.

But now the new meanings are also, (3) what version of Python is 
required by the oldest supported Meson version, and (4) what version of 
Python can be assumed by various build and test scripts.  There is 
actually (4a) scripts that are only run from a meson build, which should 
surely align with #3, and (4b) scripts that are also run by a make 
build, which is what oauth_server.py is, for which we can pick anything. 
  The answer to #3 is currently Python 3.5 (see top of top-level 
meson.build).

And then there is meaning (5) what version has anyone actually tested.

Note that #2, #3, and #4 are build-time and #1 also has a run-time 
component.  It would be plausible to say that you need a certain newer 
Python to build, but plpython can still run on older versions.  If we 
were to make any changes, we need to make sure that the documentation is 
precise about this and matches the code (see #define Py_LIMITED_API).

The cut-off in practice for these things is usually RHEL.  PG18 
currently still supports RHEL 7, which appears to come with Python 3.6. 
Seeing that the small problem with the test script was easily fixed, I 
think we should stick with that for now.  There might be value in 
dropping support for RHEL 7 sometime, but that should be done across the 
board (meson version, openssl version, perl version, etc.), and requires 
some buildfarm changes, so I wouldn't do this right now.




В списке pgsql-hackers по дате отправления: