Support python 3.13 and oneAPI 2026.1

[eap]

Apologies up-front for the weighty PR here. I've been working dilligently to get something that builds on the aws-ubuntu system and this is what I've come up with. I've coupled the changes of oneapi and python because they were all interdependent anyways and any single-purpose PR would create a similar mess to be cleaned up by the other connected PR. Putting them all in one place at least concentrates the pain.

While this was developed with oneAPI 2026.1, I suspect it would also work with 2026.0.

Nothing here is a code change to this PR — it is all upstream plumbing that has
to land before the repos/builtin submodule can be bumped and this PR merged.

Dependencies

spack/spack-packages (upstream)

• py-xarray: improve version constraints for pandas spack/spack-packages#5537
• bufr: Add meson dependency for newer python spack/spack-packages#5627
• ecflow: add v5.18.0 spack/spack-packages#5628
• hdf-eos2: fix "incompatible-pointer-types" error on modern compilers spack/spack-packages#6096
• ecflow: Add version bound to pybind for ecflow >= 5.18 spack/spack-packages#6084
• uwtools: add 2.9.1, 2.10.0, 2.11.0, 2.17.0 spack/spack-packages#5631

JCSDA/spack-packages (jspack-stack-dev)

• py-xarray: apply py-pandas version constraints to intermediate releases spack-packages#72
• Add meson dependency for newer python spack-packages#73
• Cherry pick "ecflow add v5.18.0 (#5628)" from spack/spack-packages spack-packages#74
• hdf-eos2: oneapi fix. Sync with spack-packages upstream and cherry patch from #6096. spack-packages#76
• Cherry-pick ecflow pybind11 fix (sourced from spack-packages#6084)
• Cherry-pick uwtools version fixes (sourced from spack-packages#5631)
• WIP add pyresample spack-packages#70

JCSDA/spack-stack

• Fix meta-modules preferred compiler bug #2084
• Bump the repos/builtin submodule in this PR once all cherry-picks are merged

Testing

This has been tested on Ubuntu 2024.04.

Checklist

• This PR addresses one issue/problem/enhancement or has a very good reason for not doing so.
• These changes have been tested on the affected systems and applications.
• All dependency PRs/issues have been resolved and this PR can be merged.
• All necessary updates to the documentation (spack-stack wiki) will be made when this PR is merged

[rickgrubin-noaa]

@eap perhaps also consider this request?

[climbfuji]

Hopefully we get away with duplicates of py-versioneer.

We may be able to relax one of the package constraints; quite often, these are too restrictive and simply in there because that's what the author tested with. It seems unlikely that 0.28 and 0.29 are that incompatible ...

[eap]

yeah, either way this is an upstream change that we are stuck with until fixed upstream. For the moment this feels forgivable since its only a build dep and at least I can prevent it from causing a large-scale package split.

[climbfuji]

I would like to investigate that further - so far, all py-numpy versions I used built fine with oneAPI

[eap]

hmm! I will also check