Build Windows wheels using cibuildwheel

[nulano]

For #7390:

• removed wheel building on every push to simplify test-windows.yml so libimagequant can be included there,
• moved fribidi artifact to the wheels workflow so that both x86 and x64 versions are provided,
• moved CIBW_CONFIG_SETTINGS to pyproject.toml and added build-verbosity = 1 so that build warnings are visible,
• moved modules/codecs/features check from wheels-test.sh to Tests\check_wheel.py so that it can also be used on Windows,
• added a Windows build to wheels.yml, using winbuild\build_prepare.py to build dependencies same as before, building with cibuildwheel, and testing in Docker similarly to Check available features in Windows wheels #6847.

I've included x86 also for #7443 (comment); there have been several issues opened about installing on win32. Perhaps it is not yet the time to stop providing these.

I've tested the arm64 wheels on an M2 MacBook in a Windows ARM VM using this batch script:

rem params: path\to\python.exe path\to\wheel.whl venv_dir_name

%1 -m pip install virtualenv
%1 -m virtualenv %3
cmd /c %3\Scripts\activate.bat ^&^& python -m pip install %2[tests]
powershell .github\workflows\wheels-test.ps1 %3 && echo Success!

Although the VM did have VC++ redistributable DLLs installed, I checked the list of imported dlls by the pyd files match between arm64 and amd64 with dumpbin.

[nulano]

djpeg.exe and cjpeg.exe require VC++ redistributable packages, but the whole point of testing in Docker is to not install those. Running these during CPython tests therefore crashes with a message about missing DLLs. PyPy tests do require VC++, so they are still tested there.

[nulano]

cibuildwheel downloads Python to CIBW_CACHE_PATH (set to C:\cibw above) and sets up a venv for testing at %temp%\cibw-run-<random>\<python-tag>\venv-test. It then runs the test command in the directory %temp%\cibw-run-<random>\<python-tag>\test_cwd.

The CIBW_CACHE_PATH and venv-test directories are bind-mounted here so that the venv can be used from the Docker container. The only way I could find to refer to the venv path was %CD%\..\venv-test; it might be worth opening an issue in cibuildwheel for a better solution?

[hugovk]

Could try it!

[hugovk]

Thanks for this! A quick review.

[radarhere]

I expect there's a reason, but why is it not simpler to test for tkinter by attempting to import it normally?

[nulano]

Lint error, https://github.com/nulano/Pillow/actions/runs/6998411214/job/19036420674#step:7:21:

Tests/check_wheel.py:10:16: F401 `tkinter` imported but unused; consider using `importlib.util.find_spec` to test for availability

[hugovk]

Ah, assert tkinter should silence the warning. We've done that before.

[nulano]

Yes, I remember seeing that before, but figured the linter suggestion would work as well.

I've pushed a commit to try: import tkinter instead for consistency with other optional imports (the only one I could find with a simple grep was in Image.preinit).

[hugovk]

Yeah, the others were replaced with pytest.importorskip (#4436) which doesn't fit here.

[radarhere]

Previously, this was only run for one Python version.

Pillow/.github/workflows/test-windows.yml

Lines 246 to 248 in 63bec07

	- name: Upload fribidi.dll
	if: "github.event_name != 'pull_request' && matrix.python-version == 3.11"
	uses: actions/upload-artifact@v3

Any particular reason it's now being run for every version?

[nulano]

This is now in the wheels.yml workflow which only runs a single job for all Python versions of a single architecture.
Previously it was in test-windows.yml which has a separate job for each Python version.