8000 ⚠️ CI failed on Wheel builder ⚠️ · Issue #24612 · scikit-learn/scikit-learn · GitHub
[go: up one dir, main page]
Skip to content

⚠️ CI failed on Wheel builder ⚠️ #24612

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
scikit-learn-bot opened this issue Oct 9, 2022 · 12 comments
Closed

⚠️ CI failed on Wheel builder ⚠️ #24612

scikit-learn-bot opened this issue Oct 9, 2022 · 12 comments
Labels
Blocker Bug Build / CI
Milestone
1.2

Comments

@scikit-learn-bot
Copy link
Contributor
scikit-learn-bot commented Oct 9, 2022 •
edited
Loading

CI is still failing on Wheel builder (Oct 19, 2022)
@github-actions github-actions bot added the Needs Triage Issue requires triage label Oct 9, 2022
@cmarmo cmarmo mentioned this issue Oct 9, 2022
Merged
@cmarmo cmarmo removed the Needs Triage Issue requires triage label Oct 9, 2022
@ogrisel
Copy link
Member
ogrisel commented Oct 10, 2022 •
edited
Loading

The main problem that causes the windows test runs to fail (when importing scikit-learn modules to collect the tests) seems to be a missing compiled extension:

  [...]
  Python\lib\site-packages\sklearn\datasets\__init__.py:22: in <module>
      from ._twenty_newsgroups import fetch_20newsgroups
  Python\lib\site-packages\sklearn\datasets\_twenty_newsgroups.py:46: in <module>
      from ..feature_extraction.text import CountVectorizer
  Python\lib\site-packages\sklearn\feature_extraction\__init__.py:8: in <module>
      from ._hash import FeatureHasher
  Python\lib\site-packages\sklearn\feature_extraction\_hash.py:10: in <module>
      from ._hashing_fast import transform as _hashing_transform
  E   ImportError: DLL load failed while importing _hashing_fast: The specified module could not be found.

@jjerphan
Copy link
Member

The absence of compiled extension is the source of failure for the Windows 64bit wheels only, that is:

scikit-learn/.github/workflows/wheels.yml

Lines 58 to 69 in fd0e815

- os: windows-2019
python: 38
bitness: 64
platform_id: win_amd64
- os: windows-latest
python: 39
bitness: 64
platform_id: win_amd64
- os: windows-latest
python: 310
bitness: 64
platform_id: win_amd64

The other Windows 32bit wheels, that is:

scikit-learn/.github/workflows/wheels.yml

Lines 71 to 79 in fd0e815

# Window 32 bit
- os: windows-latest
python: 38
bitness: 32
platform_id: win32
- os: windows-latest
python: 39
bitness: 32
platform_id: win32

aren't built because SciPy needs to be built from source and a Fortran compilation error occurs as stated in #24446 (comment):

 ..\..\meson.build:49:0: ERROR: Executables created by Fortran compiler gfortran are not runnable.

this might be related to the lack of a compiler toolchain for win32 as stated in this thread in Scientific Python's discourse:

For SciPy 1.9.0 we are switching to Meson as the default build system, with the numpy.distutils based build still available as a backup. Currently there is no compiler toolchain which works with the Meson build and allows us to build 32-bit wheels for distribution.

@ogrisel
Copy link
Member
ogrisel commented Oct 10, 2022 •
edited
Loading

Thanks. It's weird because there is a 32 bit windows build for scipy 1.9.1 but not for 1.9.2:

https://pypi.org/project/scipy/1.9.1/#files

I am pinning 1.9.1 for the regular CI in #24621 but I guess we will need something similar for the wheels or maybe we can temporarily (?) stop building wheels for 32 bit windows while scipy does not support it.

@ogrisel
Copy link
Member
ogrisel commented Oct 10, 2022

The absence of compiled extension is the source of failure for the Windows 64bit wheels only.

This point still needs investigation though.

@ogrisel ogrisel mentioned this issue Oct 10, 2022
Merged
@ogrisel
Copy link
Member
ogrisel commented Oct 10, 2022

As discussed in #24621, we probably should find a way to let pip use --prefer-binary when installing the build and test dependencies. Not sure how to do that with cibuildwheel though.

@EwoutH
Copy link
EwoutH commented Oct 10, 2022

@ogrisel Could this be a feature request for cibuildwheel itself?

@thomasjpfan thomasjpfan mentioned this issue Oct 10, 2022
Merged
@cmarmo
Copy link
Contributor
cmarmo commented Oct 10, 2022

The absence of compiled extension is the source of failure for the Windows 64bit wheels only.

This point still needs investigation though.

This point is solved by https://github.com/scikit-learn/scikit-learn/pull/24446/files#diff-e0a07d85249fa03c06895043f2d57076b4a1a30b195631e1682b5470db6a5ac3
Should I offer a separate PR for that?

Sorry for cross-posting, trying to make myself read... ;)

@cmarmo cmarmo mentioned this issue Oct 10, 2022
Merged
@thomasjpfan
Copy link
Member
thomasjpfan commented Oct 10, 2022 •
edited
Loading

Looking at the fix in #24631, I think the issue with Windows 64bit is that SciPy 1.9.2 no longer ships with msvcp140.dll. Unfortunately, I suspect that earlier versions of scikit-learn will not work with SciPy 1.9.2 either.

Edit: I opened an issue about this before in SciPy: scipy/scipy#14998

@ogrisel
Copy link
Member
ogrisel commented Oct 10, 2022

This point is solved by https://github.com/scikit-learn/scikit-learn/pull/24446/files#diff-e0a07d85249fa03c06895043f2d57076b4a1a30b195631e1682b5470db6a5ac3
Should I offer a separate PR for that?

I missed that. I think it's up to scipy to fix their release artifacts. We just have to wait a bit.

@EwoutH EwoutH mentioned this issue Oct 10, 2022
Merged
4 tasks
@thomasjpfan thomasjpfan mentioned this issue Oct 11, 2022
Closed
@thomasjpfan
Copy link
Member

I opened a new issue for SciPy 1.9.2 here: scipy/scipy#17191. I suspect that SciPy removed msvcp140.dll intentionally, which means that we need to develop our own workaround. For SciPy, it looks like they determined that msvcp140.dll is not needed anymore.

XREF: scipy/oldest-supported-numpy#45

@rgommers
Copy link
Contributor

So the claim in scipy/oldest-supported-numpy#45 is All versions of Python currently supported should already have msvcp140.dll. If that is true, what I guess is happening is that scikit-learn depends on it implicitly, and is counting on it being loaded in memory by Python or SciPy. However, if Python and SciPy both don't actually need the DLL anymore because they're now relying on the Windows Universal Runtime (ucrtbase.dll & co), then it won't help scikit-learn to have the DLL bundled into SciPy. It just sits there in some random directory that's not on the library search path.

Both newer MSVC versions and Mingw-w64 (which is what the SciPy wheels are now built with) should depend on the UCRT rather than on the older msvcp140.dll. So this explanation seems plausible.

You may also get end user issues who happen to not have any other program installed that already dumped the DLL into a system directory (from the last time SciPy got a bug report about that, this is rare though).

@ogrisel ogrisel added this to the 1.2 milestone Oct 12, 2022
@ogrisel ogrisel mentioned this issue Oct 18, 2022
Merged
@cmarmo cmarmo mentioned this issue Oct 18, 2022
Closed
@scikit-learn-bot
Copy link
Contributor Author

CI is no longer failing! ✅

Successful run on Oct 20, 2022

@lesteve lesteve mentioned this issue Nov 20, 2024
Merged
@jorisvandenbossche jorisvandenbossche mentioned this issue Dec 18, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Blocker Bug Build / CI
Projects
None yet
Milestone
1.2
Development

No branches or pull requests
7 participants
@ogrisel @rgommers @cmarmo @thomasjpfan @scikit-learn-bot @jjerphan @EwoutH
0