{lang}[iimkl/2023b] SciPy-bundle v2023.12

[Louwrensth]

(created using eb --new-pr)

[Louwrensth]

This feature isn't really documented

Am I allowed to use it?

[Micket]

It's not disallowed, though this would mean we e.g. aren't running test step (and all the other good stuff that presumably is done in that easyblock, like picking up fft etc.)

I would like to input from one of the authors of the numpy easyblock. I only recognize @boegel names there.

[boegel]

Specifying a custom easyblock for a particular extension like this is fine in general, but bypassing the custom easyblock for numpy specifically is a bit of a "red flag" (strongly worded).

It seems like that may point to a fix being needed in the numpy easyblock instead?

[Louwrensth]

It seems like that may point to a fix being needed in the numpy easyblock instead?

Yes, that's what I thought first too. One might say that the numpy easyblock need to evolve along with the changes in numpy's build system (v1.26.0).

Similarly to what happened to the SciPy easyblock (pr 2862), when there were changes in SciPy's build system (v1.9).

But I'm in doubt, because the new build system is (advertised as) simpler, then why would we making our easyblock more complex? If the generic pythonpackage works better than the bespoke numpy block, we have an opportunity to be leaner.

I want to do what happened with SciPy block, but I want it to be a oneliner. One test that makes it revert to the generic case, say if LooseVersion(self.version) >= LooseVersion('1.26'). I don't like the idea of adding many if self.use_meson statements in the block, doubling it.

Am I missing something? Those tests that @Micket mentioned? Please let me know what you think.

[Louwrensth]

I've added SciPy-bundle-2023.12-gfbf-2023b.eb to complete the pair (they both have the numpy extension using the spin/meson/ninja build via pip install)

I suppose a pair of version 2023.11 could be completed by adding the iimkl build, but it seems tedious to do and I think it might also not desired...

[boegel]

I'm not sure if it's a good idea to introduce another SciPy-bundle version with gfbf/2023b...

For iimkl/2023b, it's worth considering though, especially if SciPy-bundle 2023.11 isn't working out.

@Louwrensth Do you recall what kind of trouble you ran into with SciPy-bundle 2023.11 with iimkl/2023b?
Was it problems with the numpy/scipy test suite, or compilation problems?

[Louwrensth]

I'm not sure if it's a good idea to introduce another SciPy-bundle version with gfbf/2023b...

For iimkl/2023b, it's worth considering though, especially if SciPy-bundle 2023.11 isn't working out.

@Louwrensth Do you recall what kind of trouble you ran into with SciPy-bundle 2023.11 with iimkl/2023b? Was it problems with the numpy/scipy test suite, or compilation problems?

Good call. I don't recall, but I found a stash.

I'll:

1. try 2023.11-iimkl again : add SciPy-bundle-2023.11-iimkl-2023b.eb #21281
   I think it is a no-go...
2. dump 2023.12-gfbf anyway
   done.
3. add 2023.12-iimkl only if needed
   this PR?

[boegelbot]

Test report by @boegelbot
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
cns2 - Linux Rocky Linux 8.9, x86_64, Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz (haswell), Python 3.6.8
See https://gist.github.com/boegelbot/1a49b3b77cfca641d8a4b40b549a653a for a full test report.