Investigate incompatible signatures of `scipy.linalg.cython_blas.dasum`

[larsoner]

Describe your issue.

In MNE-Python we run a pip-pre job with thhe latest scipy-wheels-nightly builds for NumPy/SciPy/sklearn. The latest 1.11.0.dev0+1956.7c74503 SciPy + 1.3.dev0 sklearn pip-pre wheel combination appears to be buggy:

• https://github.com/mne-tools/mne-python/actions/runs/4816481433/jobs/8576144713?pr=11640

It worked with 1.11.0.dev0+1926.070b2a8 in SciPy:

• https://github.com/mne-tools/mne-python/actions/runs/4805236318/jobs/8551461993

Probably because SciPy changed their signature to int const * in scipy/scipy#18247.

Some form of this should allow you to reproduce the issue I think:

pip install --pre --extra-index-url "https://pypi.anaconda.org/scipy-wheels-nightly/simple" numpy scipy sklearn

This is the error message we see in CIs:

________ ERROR at setup of test_make_forward_solution_kit[testing_data] ________
mne/forward/tests/test_make_forward.py:381: in small_surf_src
    src = setup_source_space('sample', 'oct2', subjects_dir=subjects_dir,
<decorator-gen-115>:12: in setup_source_space
    ???
mne/source_space.py:1439: in setup_source_space
    s = _create_surf_spacing(surf, hemi, subject, stype, ico_surf,
mne/surface.py:1066: in _create_surf_spacing
    mmap = _compute_nearest(from_surf['rr'], ico_surf['rr'])
mne/surface.py:503: in _compute_nearest
    tree = _DistanceQuery(xhs, method=method)
mne/surface.py:525: in __init__
    from sklearn.neighbors import BallTree
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/neighbors/__init__.py:8: in <module>
    from ._distance_metric import DistanceMetric
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/neighbors/_distance_metric.py:4: in <module>
    from ..metrics import DistanceMetric as _DistanceMetric
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/__init__.py:42: in <module>
    from . import cluster
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/cluster/__init__.py:22: in <module>
    from ._unsupervised import silhouette_samples
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/cluster/_unsupervised.py:23: in <module>
    from ..pairwise import pairwise_distances_chunked
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/pairwise.py:40: in <module>
    from ._pairwise_distances_reduction import ArgKmin
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/_pairwise_distances_reduction/__init__.py:89: in <module>
    from ._dispatcher import (
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/_pairwise_distances_reduction/_dispatcher.py:11: in <module>
    from ._base import _sqeuclidean_row_norms32, _sqeuclidean_row_norms64
sklearn/metrics/_pairwise_distances_reduction/_base.pyx:1: in init sklearn.metrics._pairwise_distances_reduction._base
    ???
sklearn/utils/_cython_blas.pyx:1: in init sklearn.utils._cython_blas
    ???
E   TypeError: C function scipy.linalg.cython_blas.dasum has wrong signature (expected __pyx_t_5scipy_6linalg_11cython_blas_d (int *, __pyx_t_5scipy_6linalg_11cython_blas_d *, int *), got __pyx_t_5scipy_6linalg_11cython_blas_d (int const *, __pyx_t_5scipy_6linalg_11cython_blas_d const *, int const *))

Platform                Linux-5.15.0-1035-azure-x86_64-with-glibc2.35
Python                  3.11.3 (main, Apr  6 2023, 07:55:46) [GCC 11.3.0]
Executable              /opt/hostedtoolcache/Python/3.11.3/x64/bin/python
├☑ numpy                1.25.0.dev0+1207.gafa98ddef (OpenBLAS 0.3.21 with 1 thread)
├☑ scipy                1.11.0.dev0+1926.070b2a8
├☑ sklearn              1.3.dev0

Assuming the SciPy change was good/reasonable, it seems like sklearn should adapt to/permit this new signature type. But I might be wrong...

I've opened scipy/scipy#18377 at the SciPy end in case you want to argue with the SciPy folks that they did something wrong here

[larsoner]

This seems almost certainly due to scipy/scipy#18247 where the signature of the function was changed. So perhaps the scikit-learn wheel needs to tolerate two different signatures somehow (?) since older SciPy wheels will have int * and newer ones will have int const *.

[betatim]

Thanks for opening this and the helpful links and context.

From a brief look it sounds like scikit-learn would need to add some kind of wrapper/shim/thing so that wheels work with older and new scipy versions because of the change in the PR. (What you said.) @jjerphan or @Micky774 do you know if there is a precedence for this somewhere in the scikit-learn code base?

[jjerphan]

@jjerphan or @Micky774 do you know if there is a precedence for this somewhere in the scikit-learn code base?

Edit: I do think there is precedence for this case in scikit-learn's code-base.

[betatim]

Do you think it is possible to build a scikit-learn wheel that works with both old and new versions of scipy (from a purely technical/cython point of view)? Otherwise I think we should open an issue with them to discuss how to deal with this.

[larsoner]

Feel free to use scipy/scipy#18377 if you want to discuss with the SciPy folks

[betatim]

Actually, even if we can fix up scikit-learn so that future releases of scikit-learn can handle both the old and new signature in scipy, for versions of scikit-learn that were already released people will get failures when these scipy changes are released.