relax meson/meson-python requirements

[isuruf]

This makes bugfixes from later meson/meson-python fixes available to build pandas. For eg: python 3.13t support in meson, needs an up-to-date version of meson.

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

cc @rgommers

[rgommers]

Thanks Isuru! @lithomas1 @WillAyd we were looking at this, and these exact pins had not been updated since the initial PR that added Meson support to Pandas. I don't think there's anything specific to these versions beyond them being the most recent ones when that support got merged.

[rgommers]

We're at 0.17.0 already (with 0.17.1 coming later today). Normally in main one should not add upper bounds at all, and at most all them in release branches only. So I'd drop the upper bound here completely. If Pandas devs are attached to it, then it should be <0.18.

The lower bound can be left as is or bumped, since 0.13.1 is pretty old by now.

[WillAyd]

I'd be OK to remove the upper bound

[rgommers]

This one looks right to me. Note that newer Meson versions have more shiny features one may want (e.g., you need 1.4.0 to have dependency('numpy') work with numpy 2.0 and up, so could be bumped a bit as well if desired.

[WillAyd]

I vaguely remember trying to upgrade this in #57895 and running into issues; we might want to keep the pin here below 1.4.0 since that has some fundamental changes to how NumPy is integrated (or on the flip side, bump the min to 1.4.0, although that would be a larger task)

[lithomas1]

Feel free to bump and make that change as well :)

[lithomas1]

Thanks for the PR.

I'm OK with bumping, but I'd prefer leaving the pin in.
(This has "protected" us from bugs/breaking changes in the latest meson in the past.)

CI looks to be just red in general across pandas unfortunately.
(If someone doesn't fix the failing builds over the next couple of days, I'll go ahead and take a look myself.)

[rgommers]

I'm OK with bumping, but I'd prefer leaving the pin in.
(This has "protected" us from bugs/breaking changes in the latest meson in the past.)

Hard pins in general are never the right thing to do in main (unless the dependency is too unstable, which meson/meson-python are not), so if you really want to keep an == then I suggest:

1. Put a comment above it that this is a pre-emptive pin only, and distro maintainers can feel free to drop the pin
2. Amend your release procedure to bump the pinned version to the latest released one before each release.

If you don't do that, you will end up creating problems for distros, as well as missing out on lots of bug fixes which tend to be needed for users on niche platforms and niche compilers in particular.

[WillAyd]

Also +1 to remove the pin. I think it was really useful when we swapped over to Meson, but its probably outlived its usefulness. I've used Meson on a few other projects with only setting a minimum bound, and haven't run into issues.