GitHub Actions: Removing windows-2016 on 7 Nov

[hugovk]

The Windows Server 2016 virtual environment will be removed on November 7, 2019. You will need to update your workflow files to run on windows-latest which will run on the Windows Server 2019 environment instead.

actions/runner-images#68

We use windows-2016:

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

Line 8 in 64e1fee

runs-on: windows-2016

[hugovk]

Simply flipping to windows-latest doesn't work:

• https://github.com/hugovk/Pillow/commit/31da3994b0dd0d74c788d64a436ceec4c7c5f13a/checks?check_suite_id=292424329

[nulano]

I have a WIP rewrite of the Windows workflow in my repo, but I don't expect to have time to work on it this month. AFAICT from the log, it is having trouble finding vcvarsall.bat. There is another version in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat which needs to be called with the x86 parameter, and for Python 3.5 and PyPy3.6 with the -vcvars_ver=14.0 (this ensures the same compiler distutils finds is also used for dependencies). The second parameter might not be needed on Windows Server 2019, as I think it only has the newer compiler.

You can see my build here: https://github.com/nulano/Pillow/runs/245421431#step:7:7

Another problem that might come up, is that I am not sure if the Windows 7.1A SDK is present in the newer VS version. Some of the dependencies require files which are removed in newer SDKs.

[nulano]

I've updated the scripts: https://github.com/nulano/Pillow/runs/286210242

The following are no longer supported:

• LCMS2 hasn't been updated to support Visual Studio 2019.
• GhostScript requires v140 build tools, which are not installed on the windows-2019.
• distutils for Python 3.5 fails to find a compiler.
• distutils for Python 3.6 fails to find redistributable libraries and compiles with /MT instead of /MD. This can cause link and runtime errors.

(I believe PyPy3.6 uses distutils from Python 3.5, but it failed to install due to an intermittent network error.)

---

From actions/runner-images#68 (comment):

Does that mean Visual Studio 2017 will be added to windows-latest?

That is the plan. We don't yet have a firm ETA, but ideally by end of the year.

This should fix all above issues, but will not be done anytime soon. In the meantime, the following temporary fixes for the problems above might help:

• Using set DISTUTILS_USE_SDK=1 for distutils and adding the redistributables location into an undocumented env variable would likely fix the distutils problems.
• For LCMS2, patching the project files (from the build script) to use VS2019 and SDK 10 might work.
• Does GhostScript have to be built on the CIs? Compiling it separately and grabbing it from pillow-depends would delay this issue until a new version of GhostScript is released, and would speed up builds by 3 minutes. Modifying its build files doesn't seem trivial.

[cgohlke]

Does GhostScript have to be built on the CIs?

Excuse my ignorance, but why does GhostScript have to be built from source for Pillow?

[tvatter]

Let me know if you find a way to make it work for Python 3.5!

[nulano]

Does GhostScript have to be built on the CIs?

Excuse my ignorance, but why does GhostScript have to be built from source for Pillow?

I don't think it does, but that's how @radarhere added it in #3587, I just ported that code to GHA and added the missing dependencies.

[nulano]

Let me know if you find a way to make it work for Python 3.5!

This commit seems to fix the distutils issue: nulano@907ce50#diff-2597c013050e483c3e6ab46c4b9212c1:

+ set DISTUTILS_USE_SDK=1
+ set py_vcruntime_redist=true

See build: https://github.com/nulano/Pillow/runs/293080812

[tvatter]

Wait, for me I noticed something similar to your earlier comment ("distutils for Python 3.5 fails to find a compiler"), but here it seem to work for Python 3.5, I need to check that :)

[nulano]

Wait, for me I noticed something similar to your earlier comment ("distutils for Python 3.5 fails to find a compiler"), but here it seem to work for Python 3.5, I need to check that :)

Is there an (undocumented?) difference between windows-2019 and windows-latest? In an earlier comment you mentioned that the 14.0 vcvarsall sort of worked for you, which is how the Python 3.5 distutils looks for a compiler, [edit] unlike Python 3.6+ which uses vswhere.

[tvatter]

It worked, but only for python 3.6 and 3.7. For some reason, python 3.5 couldn't find the compiler with windows-latest yesterday. I will try this right away, that's weird.

[nulano]

I have implemented the changes I mentioned above in #4201.

There is still an issue with PyPy failing to find a compiler.