meson PortGroup: find an easier method to set the desired python rather than patch-and-reinplace python in every port

[Lord-Kamina (Gregorio Litenstein)]

I'm making a new port that used the meson-1.0 (Oh, how I hate meson) portgroup. I'm currently having trouble because meson's python module finds /usr/bin/python when asked for python3; even though both python3_select and python_select are installed.

Is this a common occurence, is there a cleaner way to fix this than patching the meson.build file to say python3.9 instead of python3?

I'll ask about this upstream also but considering bigger issues than this have been open for years over there, I don't have much faith.

[kencu (Ken)]

almost every port we have that uses meson has a small patch to meson.build and a reinplace after to spec the python you want. check any for an example -- the glib2 I updated yesterday being the last one I did.

this is kinda standard MP stuff.

upstream expects a user to make "python3" mean something in their system. MacPorts rejects requirement that requirement for port building, although individual users can do that with python_select for their own use.

If you use python_select on your development machine to select a python3, your portfile might build, but they will then error out on the buildbots anyway until you do the patch-and-reinplace.

[Lord-Kamina (Gregorio Litenstein)]

Replying to kencu:

almost every port we have that uses meson has a small patch to meson.build and a reinplace after to spec the python you want. check any for an example -- the glib2 I updated yesterday being the last one I did.

this is kinda standard MP stuff.

upstream expects a user to make "python3" mean something in their system. MacPorts rejects requirement that requirement for port building, although individual users can do that with python_select for their own use.

If you use python_select on your development machine to select a python3, your portfile might build, but they will then error out on the buildbots anyway until you do the patch-and-reinplace.

Got it. It just FEELS hacky, so I wanted to make sure that was the way to go before I went that way.

[kencu (Ken)]

It is unfortunate this is needed, and then has to be updated in many ports when the blessed python changes. But it is what we do.

[Lord-Kamina (Gregorio Litenstein)]

Replying to kencu:

It is unfortunate this is needed, and then has to be updated in many ports when the blessed python changes. But it is what we do.

Do take note of something, though...

From ​https://mesonbuild.com/Python-module.html#find_installation

That argument is optional, if not provided then the returned python installation will be the one used to run Meson.

I guess, for many ports just patching or running reinplace to change the call to find_installation could be enough.

[kencu (Ken)]

Replying to Lord-Kamina:

Replying to kencu:

It is unfortunate this is needed, and then has to be updated in many ports when the blessed python changes. But it is what we do.

Do take note of something, though...

From ​https://mesonbuild.com/Python-module.html#find_installation

That argument is optional, if not provided then the returned python installation will be the one used to run Meson.

I guess, for many ports just patching or running reinplace to change the call to find_installation could be enough.

The reproducible builds dogma says that the tools used have be deterministically specified, and cannot just be whatever is randomly found by the toolchain at the time.

So MacPorts expects the python (or other tool) used will be the same every time by all users. So the parameter is not optional for MacPorts (ideally).

That is why it is specified exactly as we do.

[kencu (Ken)]

And besides, if you're going to go to the trouble of patching and reinplacing anyway, you might as well do it right.

What would be nice is some centralized spot where the python is specified. But even then there could then be hundreds of ports that conceivably need to be revbumped to pick up a python change when the blessed python changes, if any of that is baked into scripts etc (we are trying hard to purge all that baking in for exactly this reason).

[Lord-Kamina (Gregorio Litenstein)]

Replying to kencu:

And besides, if you're going to go to the trouble of patching and reinplacing anyway, you might as well do it right.

What would be nice is some centralized spot where the python is specified. But even then there could then be hundreds of ports that conceivably need to be revbumped to pick up a python change when the blessed python changes, if any of that is baked into scripts etc (we are trying hard to purge all that baking in for exactly this reason).

It wouldn't be "what the toolchain randomly finds in the moment" though. It would always be whatever python meson itself is using; so you've got your point of centralization. Then you just need to edit meson when python changes.

[kencu (Ken)]

Oh I see what you mean. Yeah, if that worked, we'd be ahead.

[Gcenx]

Glad to see I’m not alone in this annoyance.

[mascguy (Christopher Nielsen)]

Add keyword portgroup, to pg-related tickets

[ryandesign (Ryan Carsten Schmidt)]

In ac42249d9868eb46bf0f968997064d4a006f542b/macports-ports (master):

meson pg: add meson.native.binaries option

Ports can append key=value pairs to meson.native.binaries to override
the results of find_program.

See: #63356
See: mesonbuild/mesonhttps://github.com/macports/macports-ports/pull/13096

[ryandesign (Ryan Carsten Schmidt)]

The existence of meson.native.binaries addresses this issue.

To override meson's choice when a meson.build file uses find_program('foo'), use:

meson.native.binaries-append \
                    foo=${prefix}/bin/foo

To override meson's choice when a meson.build file uses import('python').find_installation('python3'), use e.g.:

meson.native.binaries-append \
                    python=${prefix}/bin/python3.12