✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: cc098dd. Link to the linter CI: here}

Given that numpy and scipy dropped support for python 3.8, I think it's fine to do it as well. We still support 3 versions of Python.

Tests are failing btw, something wrong with the min deps

Tests are failing btw, something wrong with the min deps

I forgot to bump SciPy in the pyproject.toml. We should get closer to the right solution :).

This is weird. For the second time, the build for the default channel is failing and I see that the job that is having a timeout has some failure before to timeout.

I would think that we need to investigate the reason to see if we reproduce locally. Maybe NumPy or SciPy version of the default channel is yanked.

Could you re-run the failing CI job with --max-fail=10 so that we get details on the problem before reaching the timeout?

We might want to add --max-fail=10 by default in all our CIs as most of the time, when we get a very large number of failures at once, they are caused by a few common causes and trying to exhaustively analyze a gigantic error log is counter productive. We tend to fix problems incrementally when it happens.

I don't think we should block anything for conda default channel though. We've had issues not related to us in the past.

I don't think we should block anything for conda default channel though. We've had issues not related to us in the past.

I don't think this is a big deal here. This is just that we need to set the right version of scipy and numpy. I am actually wondering why we use the minimum when it comes to the defaults channel

Edit: actually we have one such build: pylatest_conda_mkl_no_openmp

Uhm it seems that the issue was only transient.

Please also rerun with [cd build] once more just to be sure.

Uhm it seems that the issue was only transient.

Looks like it has come back: https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=61583&view=logs&j=66042141-7fd2-581d-812e-1a1b1d5e0f0c&t=3bc9bdaf-ce35-5f52-15e7-faffb90cfcaf

Looks like it has come back

OK I will push-back with the maxfail flag. I just hope that this flag does not scare the errors :P

Youpi!!!!:

ValueError: On entry to DLASCL parameter number 4 had an illegal value

I am betting on upgrading to SciPy 1.6.2 as it will be useful to #27943.

So I bumped to 1.7 SciPy on the pymin defaults channel. because 1.5/1.6 seems to fail. I will make a new push to be sure that 2 successive builds are working.

Merging this one since we have 3 approvals and the CI is passing.

FYI, quickly looking at it, it seems like scipy 1.6 is the first release that officially supports Python 3.9
see 1.6 setup.py and 1.5 setup.py. Also Python 3.9 wheels are only available for scipy 1.6.

I set 1.6.0 because this is the version in debian 32-bits with python 3.9

Now that scikit-learn 1.5 is released, it might be worth considering dropping Python 3.9 (and thus requiring Python 3.10+) towards the development of scikit-learn 1.6.

This would follow SPEC 0, which recommends dropping Python 3.9 in late 2023.

As far I recall, we had an internal vote regarding endorsing the SLEP0. We should probably close the vote and check if we endorse it or not.

In case of not endorsing it, I recall that we mentioned that we would write how we would bump version to avoid this type of recurrent discussion.

As far I recall, we had an internal vote regarding endorsing the SLEP0. We should probably close the vote and check if we endorse it or not.

In case of not endorsing it, I recall that we mentioned that we would write how we would bump version to avoid this type of recurrent discussion.

@glemaitre was there any update on this? I am trying to integrate array-api-extra in gh-30340 which requires Python>=3.10 as per https://scientific-python.org/specs/spec-0000/, but there are failures due to sklearn still supporting Python 3.9.

At the end, we decided to not endorse the SLEP000. We apply a more conservative policy and in general people were not keen into endorsing a recommendation that we don't follow in the project.

Regarding the specific here, we might consider dropping support for Python 3.9 before the release of 1.7 since we already support 5 versions currently. The fact that the array-api-extra is failing is an potentially an argument for it. However, Python 3.9 "end-of-life" is Oct. 2025. Looking at the failure, it is a bit of a pity that it is caused by typing that it is something that we barely use in the code base.

Okay, thanks. A big +1 from me if you could consider dropping 3.9 soon!