fix: avoid cp39-musllinux_aarch64 timeout

[ddelange]

Supersedes #2433, see also scipy/oldest-supported-numpy#86

on master there is only one failing wheel build: https://github.com/vaexio/vaex/actions/runs/10835977160/job/30068700570

due to oldest-supported-numpy selecting a version of numpy for which no wheels are available. building numpy from source under QEMU takes forever, so we're hitting the builtin github actions 6 hour timeout (which can't be increased)

[ddelange]

@maartenbreddels CI now finishes consistently within 2 hours

[ddelange]

opened scipy/oldest-supported-numpy#85

[ddelange]

according to oldest-supported-numpy deprecation notice, we can require numpy~=1.25 (or numpy v2) in the build-system, and the compiled vaex should become backwards compatible.

[ddelange]

Closing in favour of #2435

[ddelange]

Ah no actually, reopening. this PR is needed regardless of #2435, due to the cp38-musllinux_aarch64 timeout.

or we deprecate py3.8 cc @EwoutH instead of this PR

[ddelange]

ready for review jongens @maartenbreddels @EwoutH

cleanest way I can think of whilst keeping cp38 support, at least on macos and most of linux

[EwoutH]

Looks good to me!

(note I’m not an maintainer or formally involved in this project in any way)

[ddelange]

@maartenbreddels fingerprinting is broken again.

comparing the uv pip freeze outputs from the last two commits, it's probably due to a dask release:

- dask==2024.8.2
+ dask==2024.9.0

[maartenbreddels]

it's probably due to a dask release:

Too bad, they were so stable before.

[ddelange]

looks like fingerprinting is now random (not a fingerprint anymore). will pin dask<2024.9 instead of the last two commits

[ddelange]

@maartenbreddels green again

[maartenbreddels]

Awesome, thanks!