Skip to content
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.

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

GitHub Actions: Removing windows-2016 on 7 Nov #4188

Closed
hugovk opened this issue Nov 1, 2019 · 11 comments · Fixed by #4201
Closed

GitHub Actions: Removing windows-2016 on 7 Nov #4188

hugovk opened this issue Nov 1, 2019 · 11 comments · Fixed by #4201

Comments

@hugovk
Copy link
Member

hugovk commented Nov 1, 2019

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:

runs-on: windows-2016

@hugovk
Copy link
Member Author

hugovk commented Nov 1, 2019

@nulano
Copy link
Contributor

nulano commented Nov 2, 2019

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
Copy link
Contributor

nulano commented Nov 2, 2019

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
Copy link
Contributor

cgohlke commented Nov 6, 2019

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
Copy link

tvatter commented Nov 6, 2019

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

@nulano
Copy link
Contributor

nulano commented Nov 7, 2019

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
Copy link
Contributor

nulano commented Nov 7, 2019

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
Copy link

tvatter commented Nov 7, 2019

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
Copy link
Contributor

nulano commented Nov 7, 2019

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
Copy link

tvatter commented Nov 7, 2019

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
Copy link
Contributor

nulano commented Nov 7, 2019

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants