This is good to go. @charris, @mattip, @seberg, or @stefanv anyone want to have a look, or give a thumbs up here to merge? I'd like to get things unblocked for the 1.26.0 pre-release ideally by the end of today.

LGTM. It will help with the backports if they are done in the correct order, so having that documented somewhere is desirable. Will all the linked OpenBLAS libraries all be 32 bits?

LGTM. It will help with the backports if they are done in the correct order, so having that documented somewhere is desirable.

Thanks for having a look. And sure, I will post a comment with an ordered list once we're ready to do them all.

Will all the linked OpenBLAS libraries all be 32 bits?

No, that's just for these couple of jobs here I think. All the wheel builds are using 64-bit OpenBLAS, so there is no change compared to 1.25.0 I believe.

In it goes then. On to gh-23096

This went in less than an hour after I was pinged to review, so unfortunately I didn't have time to give feedback. I think vendoring the whole of spin is almost certainly the wrong way to go, since it vastly complicates maintaining what is supposed to be a lean cmds.py.

I'll see what I can do to clear things up in a follow-up PR.

Just to understand the context here, why are we vendoring meson instead of installing it from, e.g., github?

I think vendoring the whole of spin is almost certainly the wrong way to go

I'm pretty sure that it is not. I burned 1.5 days on suggestions to avoid it, without success. The problem is that both meson-python and spin call subproces.run(['meson', ...]) and that will not work on Windows with the vendored Meson we now have. See #24379 (comment) and following comments.

Just to understand the context here, why are we vendoring meson instead of installing it from, e.g., github?

Because we need mesonbuild/meson#11307 to add SIMD support, and that's a large PR that isn't in a released Meson version. Since Meson by design cannot be extended by a third-party plugin or some such thing, we vendor it until our changes have been upstreamed and released.

Note that this is temporary, it will go away. So no worries about a long-term split of spin.

If you want the vendored content to go away asap, then there must be a way in spin itself to set the meson_cli executable as done in this PR. This is the key bit:

# The numpy-vendored version of Meson
meson_cli = [sys.executable,
             str(pathlib.Path(__file__).parent.parent.resolve() /
                 'vendor

That may be a nice feature to have in case this happens again.

I had a really hard time with debugging this stuff by the way. spin swallows tracebacks, so all I got were one-liners like:

abort: 'meson' is not a recognized command

or some such thing. Have you seen that too? You should be able to reproduce this by changing the 'meson' string to 'nonexisting'` in any command.

I'll get a spin PR ready ASAP; I'm sorry to hear you lost time on this :/

LGTM. It will help with the backports if they are done in the correct order, so having that documented somewhere is desirable.

@charris I think we're ready for the backports now, in this order:

• ENH: Vendor meson for multi-target build support #24379
• this PR
• BLD, SIMD: The meson CPU dispatcher implementation  #23096
• MAINT: Remove versioneer #24196

I'd suggest then adding an xfail on the 1.26.x branch for gh-24399. At that point, we should have everything working, and we can add release notes and tag a pre-release. I suggest making it a beta rather than an RC, because it's highly likely that we'll have to make further tweaks. It also is a flag to downstream perhaps that they should actually pay attention to their build logs.

I think we're ready for the backports now, in this order:

Great, let's see how it goes.

The backports went in without much trouble.