@cmarmo: would you be interested to work on this? 🙂

Cross-referencing a related discussion on scientific-python.org for inter-project coordination:

• https://discuss.scientific-python.org/t/spec-4-nightly-wheels/474/3

@cmarmo: would you be interested to work on this? slightly_smiling_face

@jjerphan: yes, if I am allowed to experiment a bit, but please don't expect a quick PR, it seems to me that some details should still be fixed in a number of dependencies.

I have started to work on this on my fork, to avoid using scikit-learn gh-action time.

• The two MacOS wheels are failing during the build with the same error (see eg the x86_64 build): I don't know why, if someone has any idea about that, I would be happy to hear it... :).
• The windows wheel is failing during testing with the error

  manifest for winamd64/python:3.11-windowsservercore not found: manifest unknown: manifest unknown
  

  This is because for now only the image winamd64/python:3.11-rc-windowsservercore is available... I think I can manage this.
• The linux build fails during the tests: the failing test is test_grid_search_failing_classifier in sklearn/model_selection/tests/test_search.py.

I have two questions:

• scikit-learn CI does not test against python 3.11, perhaps is time to add 3.11 to the CI?
• should I prioritize the wheel generation and do not test them? Or it is better to make all the tests (or at least those that already pass against previous python version) pass with 3.11?

Thanks!

scikit-learn CI does not test against python 3.11, perhaps is time to add 3.11 to the CI?

As far as I know, there is no released version of our dependencies that targets 3.11-rc for now. Let's wait for stable releases to be published before bumping up the Python version in our -latest CI entries.

I think we should not make development versions part of the default CI jobs running in pull requests to avoid annoying contributors with failures that might come from changes in the unreleased dev branches but we should definitely run our "scipy-dev" scheduled run on a nightly basis on Python dev (using the latest nightly builds of all our dependencies, including CPython itself) if possible.

should I prioritize the wheel generation and do not test them? Or it is better to make all the tests (or at least those that already pass against previous python version) pass with 3.11?

I would rather not publish wheels with broken tests, even for nightly builds. Let's fix them along the way in dedicated PRs.

For the failing assertion on rank, replacing:

assert ranks[0] <= 2 and ranks[1] <= 2

by:

assert ranks[0] <= 2 and ranks[1] <= 2, ranks

should give us more information on what's happening and allow us to report an issue upstream if this is a regression in numpy or Python.

@jeremiedbb I am milestoning this issue for 1.2 because we will need to fix the build on 3.11 before releasing. This might even be considered a blocker for the 1.2 release.

I am having an issue with pandas: it is a dependency for the tests, but there are no pandas wheels for python 3.11.
On linux the source is downloaded and compiled, on Windows the source is downloaded but the compilation fails with

Error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools": https://visualstudio.microsoft.com/visual-cpp-build-tools/

May I suggest to skip tests depending on pandas for now? I don't feel like it is worth it to reinstall a compiler into the window docker image for a border line situation. Also, perhaps if nicely asked, pandas people would be willing to embrace the movement and produce a wheel for python 3.11?

+1 for skipping the tests depending on pandas (or other optional dependencies) on the dev builds while they do not provide nightly builds for CPython dev.

About the other tests failures with numpy / scipy dev, our bot has automatically open this issue to track them: #24424