I confirmed that SciPy is building with the previously added patches, and all tests pass with no new failures. With this PR, we will be up to date with SciPy on PyPI and just (a little) behind the SciPy main branch/development branch(es).

I could spend some time looking into the install tags feature in this PR, which was carried over from the previous one. Since @rgommers mentioned in #5012 (comment) that all (test and non-test) modules are built and install tags affect just the install-time functionality, it might make sense to separate SciPy into two packages/recipes, scipy and scipy-tests, and run tests from scipy-tests?

SciPy tests are passing: https://github.com/pyodide/pyodide/actions/runs/10522073173/job/29155301916

is it possible to build tests only? Or do you mean having two scipy packages w/ tests and w/o tests?

It should be test-only. How to do it is documented at http://scipy.github.io/devdocs/building/redistributable_binaries.html#stripping-the-test-suite-from-a-wheel-or-installed-package. It should take almost no extra time to build two wheels if you follow the hint on caching in those docs.

Yes, I meant "scipy (without tests)" and "scipy (tests only)", indeed. Here's how I can envision this working:

• such that a new recipe for scipy-tests is created that will depend on scipy,
• the test-related configuration and files will be moved to scipy-tests so that the tests will be running from there instead of from scipy,
• this way, both packages would be installed at the time of testing, and
• we would need an extra patch that changes the package name from scipy to scipy-tests, while the rest of the patches will remain the same as the earlier ones.

I'll have to see how to cache the builds because two separate recipes would mean that both packages are built in different directories (their own ones next to their meta.yaml files), which brings forth a few problems as noted below.

Initially, I tried storing the built files for both under a common location that can be accessed, say, i.e., $PYODIDE_ROOT/scipy_builds/, but it turns out that these environment variables are set just for the script: section, and are not available for the backend-flags: section (they're empty at that stage of the build) – so we'll either need to improvise a bit in hacky ways, or make PYODIDE_ROOT available everywhere on the pyodide-build side (I'm not sure how desirable that would be, though).

Even if I specify something like ../scipy/build/ as the build directory to go back up and into scipy/, it seems to ignore that. Then, I tried some custom commands in the scipy-tests's recipe's script: section to copy over the built files, while making scipy a host dependency of it so that they are never built at the same time (and instead one after the other):

# copy files from the previously-built scipy before scipy-tests is built
cp -r $PYODIDE_ROOT/packages/scipy/build/scipy-$SCIPY_VERSION/scipy_build_cache/ \
$PYODIDE_ROOT/packages/scipy-tests/build/scipy-tests-$SCIPY_VERSION/scipy_build_cache/

This leads to failures because something like /tmp/tmptv0lxkva/cc isn't going to be defined once another recipe's build starts. If I have to proceed this way, I need to disable build isolation (i.e., in line with the -wnx suggestion in the documentation) which is something to be done by the build frontend. We currently don't have a frontend-flags: field where we can pass on pypa/build's --no-isolation equivalent, because we don't support this option in the pyodide build command yet. This seems to be a blocker for getting this runtime-and-test separation going. Should I try to add support for this option in pyodide-build, or is there a better way to handle this problem that I might be missing?

Nonetheless, this problem is a blocker only for building the scipy-tests package "efficiently", and not for updating SciPy to version 1.14.1. Building scipy-tests non-efficiently without caching would work, too, but it is redundant, of course, and I'm not too keen on doing that for our CI.

If this task takes too much time, then there is a case to be made about incorporating this enhancement as part of a follow-up PR, since this PR has brought us close to a potential out-of-tree Pyodide build and CI job for SciPy – provided that the circumventions around the Fortran problems/patches/ints-vs-voids are only going to reduce in the future via scipy/scipy#18566. I'm not a SciPy maintainer, and nor have I followed its development daily as much as @rgommers has continued to do over the last twenty years, but I don't think the files that are problematic for us are touched every day in PRs that would make Pyodide-related debugging too painful. This is backed by the fact that we have been fortunate to need a relatively lesser amount of changes for v1.13.0 ⟹ v1.14.1 in comparison to the extent of what we needed for v1.12.0 ⟹ v1.13.0, all of which makes me feel quite optimistic about it all in the future :)

I'll have to see how to cache the builds because two separate recipes would mean that both packages are built in different directories

Ah, that is going to be a pain, and probably not worth it. For conda-forge the recipe is "multi-output", so it builds two packages at once. If we cannot build two wheels from a single recipe here, then I'd forget about using this functionality for now (Pyodide already has a mechanism to strip tests, so using install tags isn't necessary).

Nonetheless, this problem is a blocker only for building the scipy-tests package "efficiently", and not for updating SciPy to version 1.14.1. Building scipy-tests non-efficiently without caching would work, too, but it is redundant, of course, and I'm not too keen on doing that for our CI.

agreed

a potential out-of-tree Pyodide build and CI job for SciPy [...] but I don't think the files that are problematic for us are touched every day in PRs that would make Pyodide-related debugging too painful

I'd like to wait with trying this, since there are still too many Fortran-related patches and I don't think it's reasonable to ask SciPy maintainers to deal with those.

Nonetheless, this problem is a blocker only for building the scipy-tests package "efficiently", and not for updating SciPy to version 1.14.1. Building scipy-tests non-efficiently without caching would work, too, but it is redundant, of course, and I'm not too keen on doing that for our CI.

Thanks for looking into it. As Ralf mentioned, I don't think it is that worth it unless the build time of scipy-tests takes too long, especially we are going to unvendor recipes. So, for now, let's just build it twice.

Thanks for looking into it. As Ralf mentioned, I don't think it is that worth it unless the build time of scipy-tests takes too long, especially we are going to unvendor recipes. So, for now, let's just build it twice.

Just to clarify, @ryanking13 – scipy and scipy-tests will be built in the same amount of time, and it would increase the CI time for the build-packages-numpy-dependents job by ~5-10 minutes, since we have three threads running at once in CircleCI. The currently existing functionality to strip the tests with unvendor-tests: true would be better instead of building twice, wouldn't it?

The currently existing functionality to strip the tests with unvendor-tests: true would be better instead of building twice, wouldn't it?

Yes, that sounds reasonable to me.

Great! Merging this PR, then, since all [scipy] tests are passing.

Thanks @agriyakhetarpal!