From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Replace uses of deprecated Python module distutils.sysconfig |
Date: | 2022-01-19 00:18:11 |
Message-ID: | 426613.1642551491@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Are we sure it's an issue within Python, rather than something we
> could dodge by invoking sysconfig differently? It's hard to believe
> that sysconfig could be totally unfit for the purpose of finding out
> the include path and would remain so for multiple years.
I dug up a Debian 9 image and found that I could reproduce the problem
against its python2 (2.7.13) installation, but not its python3 (3.5.3):
$ python2 -m sysconfig | grep include
include = "/usr/local/include/python2.7"
platinclude = "/usr/local/include/python2.7"
...
$ python3 -m sysconfig | grep include
include = "/usr/include/python3.5m"
platinclude = "/usr/include/python3.5m"
...
Looking at the buildfarm animals that failed this way, 10 out of 11
are using python 2.x. The lone exception is Andrew's prion. I wonder
if there is something unusual about its python3 installation.
Anyway, based on these results, we might have better luck switching to
sysconfig after we start forcing python3. I'm tempted to resurrect the
idea of changing configure's probe order to "python3 python python2"
in the meantime, just so we can see how much of the buildfarm is ready
for that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-01-19 00:39:07 | Re: In-placre persistance change of a relation |
Previous Message | Peter Smith | 2022-01-19 00:16:20 | tab-complete COMPLETE_WITH_ATTR can become confused by table-lists. |