Opened 8 months ago

Closed 6 months ago

Last modified 6 months ago

#68208 closed enhancement (fixed)

meson, ninja: convert to py-{meson,ninja} to support the "meson-python" PEP517 backend

Reported by: reneeotten (Renee Otten) Owned by: reneeotten (Renee Otten)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: ryandesign (Ryan Carsten Schmidt), SoapZA, jmroot (Joshua Root), kencu (Ken)
Port: meson, ninja

Description

Some ports including py-scipy have switched to meson-python as their PEP517 build backend. For this to work in MacPorts one would need to convert the current meson and 'ninja' ports to the typical py-meson and py-ninja ones, where there will be subports for each Python version that needs to use the meson-python backend.

There is some patching going on for older systems in these ports for which I haven't completely figured out what is happening there and if this can just be one-to-one ported/copied. Additionally, there is the meson PortGroup (used by ~130 ports currently) that will likely need to be adjusted.

Before attempting such a change to provide support for the new Python build-backend based on meson, I thought to solicit some advice/suggestions here. Did anyone look at this already and/or are there any immediate considerations to take into account here?

Thanks, Renee

Change History (12)

comment:1 Changed 7 months ago by jmroot (Joshua Root)

Sounds reasonable. The meson and ninja ports could continue to exist and just depend on and supply the necessary symlinks to the versions for the current preferred python version, so that the existing dependents don't have to change anything.

comment:2 in reply to:  1 Changed 7 months ago by reneeotten (Renee Otten)

Replying to jmroot:

Sounds reasonable. The meson and ninja ports could continue to exist and just depend on and supply the necessary symlinks to the versions for the current preferred python version, so that the existing dependents don't have to change anything.

thanks Josh, that's a good suggestion and keeping the meson and ninja ports so that dependents on those don't need to be changed will minimize the amount of work needed here. I'll look into making these changes in the -hopefully- near future.

comment:3 Changed 7 months ago by reneeotten (Renee Otten)

comment:4 Changed 7 months ago by reneeotten (Renee Otten)

Owner: set to reneeotten
Resolution: fixed
Status: assignedclosed

In 46fcfcb0cad1ed1adec2122aed9fa1758f199914/macports-ports (master):

meson: depend on pyXY-meson, where XY is MacPorts default

Closes: #68208

comment:5 Changed 6 months ago by joefowler (Joe Fowler)

Resolution: fixed
Status: closedreopened

The initial discussion covers changing ports meson and ninja and adding new ports py-meson and py-ninja. I think the issue was resolved prematurely: the resolution only covers meson and not ninja.

I am having problems with a port update that I think result from needing to use py-ninja (CI errors here). Can someone who understands the problem also make the change to change ninja into py-ninja?

comment:6 Changed 6 months ago by reneeotten (Renee Otten)

I can take a look at it. But, this has to do with the “meson” PEP517 build and that doesn’t need pyXY-ninja versions, so this issue is resolved. Typically re-opening a ticket for an unrelted reason is not recommended but leave it open for now and I’ll try to take a look.

comment:7 Changed 6 months ago by joefowler (Joe Fowler)

I re-opened because I understood the initial discussion to conclude that py-ninja ought to be exist. But of course, I could open a new ticket instead.

comment:8 Changed 6 months ago by reneeotten (Renee Otten)

Joe: you are not using it correctly. It looks like the PEP517 backend for py-fabio has changed to meson-python; instead of adding dependencies manually you should use: python.pep517_backend meson

So it is related to this initial ticket, but it was solved correctly in the commit that closed this ticket. If you checked the usage in the {{{python}} PortGroup it would have worked ;) Please try that again and comment here whether that solved your issue or if there is anything else that comes up.

comment:9 Changed 6 months ago by jmroot (Joshua Root)

You're right that it's better to use python.pep517_backend, but it looks like fabio does explicitly list ninja in its dependencies: https://github.com/silx-kit/fabio/blob/main/pyproject.toml#L55

That's probably unnecessary since it's only directly using meson? The ninja project on pypi is this, BTW: https://github.com/scikit-build/ninja-python-distributions

comment:10 in reply to:  9 Changed 6 months ago by reneeotten (Renee Otten)

Resolution: fixed
Status: reopenedclosed

Replying to jmroot:

You're right that it's better to use python.pep517_backend, but it looks like fabio does explicitly list ninja in its dependencies: https://github.com/silx-kit/fabio/blob/main/pyproject.toml#L55

well, that's probably not needed and you might be able to patch it out.

That's probably unnecessary since it's only directly using meson? The ninja project on pypi is this, BTW: https://github.com/scikit-build/ninja-python-distributions

Perhaps, I don't have interest in doing anything with that as it is not needed for the meson-python backend. But of course you can port that if you have interest or it is needed for anything that you maintain.

comment:11 Changed 6 months ago by jmroot (Joshua Root)

Sure. I just hope this won't be a widespread thing like oldest-supported-numpy.

comment:12 in reply to:  11 Changed 6 months ago by reneeotten (Renee Otten)

Replying to jmroot:

Sure. I just hope this won't be a widespread thing like oldest-supported-numpy.

Agreed, that would be very annoying... but looking at the documentation of meson-python the explicit listing of ninja isn't given in the examples, so hopefully this is just an oversight from fabio upstream. At least, it's worth bringing it up there.

For the two ports that initially prompted this addition (py-contourpy and py-scipy) it isn't listed as an explicit dependency. I have other issues with SciPy right now though in that I can't get it to work with the MKL variant, which is the one I would prefer...

Note: See TracTickets for help on using tickets.