Thread: Python installation selection in Meson
I noticed that under meson, the selection of the Python installation using the 'PYTHON' option doesn't work completely. The 'PYTHON' option determined the Python binary that will be used to call the various build support programs. But it doesn't affect the Python installation used for PL/Python. For that, we need to pass the program determined by the 'PYTHON' option back into the find_installation() routine of the python module. (Otherwise, find_installation() will just search for an installation on its own.) See attached patch. I ran this through Cirrus, seems to work.
Attachment
Hi, On 2023-11-28 19:02:42 +0100, Peter Eisentraut wrote: > I noticed that under meson, the selection of the Python installation using > the 'PYTHON' option doesn't work completely. The 'PYTHON' option determined > the Python binary that will be used to call the various build support > programs. But it doesn't affect the Python installation used for PL/Python. > For that, we need to pass the program determined by the 'PYTHON' option back > into the find_installation() routine of the python module. (Otherwise, > find_installation() will just search for an installation on its own.) See > attached patch. I ran this through Cirrus, seems to work. Makes sense! Greetings, Andres Freund
On 2023-11-28 Tu 13:02, Peter Eisentraut wrote: > I noticed that under meson, the selection of the Python installation > using the 'PYTHON' option doesn't work completely. The 'PYTHON' > option determined the Python binary that will be used to call the > various build support programs. But it doesn't affect the Python > installation used for PL/Python. For that, we need to pass the > program determined by the 'PYTHON' option back into the > find_installation() routine of the python module. (Otherwise, > find_installation() will just search for an installation on its own.) > See attached patch. I ran this through Cirrus, seems to work. I noticed when working on the meson/windows stuff that meson would try to build plpython against its python installation, which failed miserably. The workaround was to abandon separate meson/ninja installations via chocolatey, and instead install them using pip. Maybe this was as a result of the above problem? cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
On 29.11.23 14:23, Andrew Dunstan wrote: > > On 2023-11-28 Tu 13:02, Peter Eisentraut wrote: >> I noticed that under meson, the selection of the Python installation >> using the 'PYTHON' option doesn't work completely. The 'PYTHON' >> option determined the Python binary that will be used to call the >> various build support programs. But it doesn't affect the Python >> installation used for PL/Python. For that, we need to pass the >> program determined by the 'PYTHON' option back into the >> find_installation() routine of the python module. (Otherwise, >> find_installation() will just search for an installation on its own.) >> See attached patch. I ran this through Cirrus, seems to work. > > I noticed when working on the meson/windows stuff that meson would try > to build plpython against its python installation, which failed > miserably. The workaround was to abandon separate meson/ninja > installations via chocolatey, and instead install them using pip. Maybe > this was as a result of the above problem? That sounds like it could be the case.
On 28.11.23 19:16, Andres Freund wrote: > On 2023-11-28 19:02:42 +0100, Peter Eisentraut wrote: >> I noticed that under meson, the selection of the Python installation using >> the 'PYTHON' option doesn't work completely. The 'PYTHON' option determined >> the Python binary that will be used to call the various build support >> programs. But it doesn't affect the Python installation used for PL/Python. >> For that, we need to pass the program determined by the 'PYTHON' option back >> into the find_installation() routine of the python module. (Otherwise, >> find_installation() will just search for an installation on its own.) See >> attached patch. I ran this through Cirrus, seems to work. > > Makes sense! I have committed this, and also backpatched to 16 to keep the behavior consistent.