From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeremy Harris <jgh(at)wizmail(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Python versions (was Re: RHEL 8.0 build) |
Date: | 2018-11-28 21:20:44 |
Message-ID: | 044b778b-2086-1c3e-4ee0-fb688a7b0b80@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27/11/2018 18:30, Andres Freund wrote:
> ISTM we should first go for python, python2, python3 in all branches,
> and then have a separate master only commit that changes over the order
> to prefer python3 over 2. I don't think preferring 3 over 2 would be
> appropriate for past branches, but it'll surely become more common to
> run into distros without "python" installed.
Thinking about this some more ... Leaving RHEL 8 aside, it would be
reasonable to update the search order to "python, python3". That is
because the next round of Linux distros is moving to Python 3 as their
default, and a fresh install will only provide "python3" and no
"python". (You can still install "python"+"python2" separately, at
least for a while.) They might change "python" to point to "python3" in
the future, but that is currently undecided. There will be a window of
time where only "python3" will exist in default installations.
(Note that adding "python2" to the search list doesn't affect the above
argument, because those installations won't have that either.)
Now, about RHEL 8. The reason why RHEL 8 doesn't have "python" is
explained here:
https://developers.redhat.com/blog/2018/11/27/what-no-python-in-rhel-8-beta/.
The summary is: They can't decide what "python" should point to and
don't want to be stuck with a decision for 10 years that might end up
being incompatible with where the rest of the world moves (via a PEP 394
update).
That's something we should consider as well. We need to maintain these
decisions for about 5 years, but it's quite plausible that significant
changes (or explicit decisions not to change anything) will happen
within that timeframe. So, for example, if we were to backpatch the
search order "python, python2, python3" to PG11 and then in a few years
"python" points to "python3", then we'll end up with an effective search
order of "python3, python2, python3" which might be confusing and would
create weird inconsistencies across different releases of the same
operating system distribution. The fewer things we put in the search
list, the fewer chances of weird confusion and unexpected behavior we'll
have.
My suggestion is to either
- Change the probe order to python, python3 in master, or
- Don't change anything until PEP 394 is updated.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-11-28 21:34:26 | Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements |
Previous Message | Thomas Munro | 2018-11-28 21:19:30 | Re: "pg_ctl: the PID file ... is empty" at end of make check |