Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9yg9-0006KB-Jg for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jan 2022 00:18:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n9yg8-0003sq-DW for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jan 2022 00:18:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9yg8-0003sh-4B for pgsql-hackers@lists.postgresql.org; Wed, 19 Jan 2022 00:18:20 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9yg5-0003RB-N7 for pgsql-hackers@lists.postgresql.org; Wed, 19 Jan 2022 00:18:19 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 20J0IBuw426614; Tue, 18 Jan 2022 19:18:11 -0500 From: Tom Lane To: Peter Eisentraut cc: Andrew Dunstan , pgsql-hackers@lists.postgresql.org Subject: Re: Replace uses of deprecated Python module distutils.sysconfig In-reply-to: <322779.1642525461@sss.pgh.pa.us> References: <0cd3579e-7790-aa05-0202-c6ce14d0af73@enterprisedb.com> <3777643.1639056683@sss.pgh.pa.us> <312939.1642519464@sss.pgh.pa.us> <7129af76-acf6-f4d5-0de6-a479f75d8ad7@enterprisedb.com> <322779.1642525461@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Tue, 18 Jan 2022 12:04:21 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <426612.1642551491.1@sss.pgh.pa.us> Date: Tue, 18 Jan 2022 19:18:11 -0500 Message-ID: <426613.1642551491@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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