Omit installing vcpython27 on Windows CI #3477

New Issue

sajith · 2020-10-15T18:15:22Z

sajith commented

2020-10-15 18:15:22 +00:00

I just published zfec 1.5.4 to PyPI, which includes a bunch of wheel packages for Windows, macOS, and Linux. That means that most users of zfec, including CI, will no longer need to install a compiler in order to install zfec.

We can now omit the time-consuming (about 2m30s) step of installing vcpython27 for Windows CI.

I just published zfec 1.5.4 to PyPI, which includes a bunch of wheel packages for Windows, macOS, and Linux. That means that most users of zfec, including CI, will no longer need to install a compiler in order to install zfec. We can now omit the time-consuming (about 2m30s) step of installing vcpython27 for Windows CI.

sajith added the

labels 2020-10-15 18:15:22 +00:00

sajith added this to the undecided milestone 2020-10-15 18:15:22 +00:00

sajith self-assigned this 2020-10-15 18:15:22 +00:00

exarkun commented

2020-11-06 18:06:50 +00:00

Related issues:

Related issues: * <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3494> * <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3497>

sajith commented

2020-11-12 15:07:50 +00:00

I published zfec 1.5.4 on 2020 October 15, but it turned out that wheel package for Windows + Python 2.7 was broken. Tahoe-LAFS CI failed to use zfec-1.5.4, with this error message:

zfec: None [(<type 'exceptions.ImportError'>, 'DLL load failed: %1 is not a valid Win32 application.', ('d:\\a\\tahoe-lafs\\tahoe-lafs\\.tox\\py27-coverage\\lib\\site-packages\\zfec\\__init__.py', 13, '<module>', 'from ._fec import Encoder, Decoder, Error'))]

(Seems that those error messages when CI was restarted.)

This is the corresponding issue on zfec's tracker. I went ahead and deleted zfec 1.5.4 wheel files packaged for Windows from PyPI, in order to avoid further CI disruption.

I've uploaded zfec 1.5.5 to pypi today (2020 November 12), which has been tested a little more. I updated cibuildwheel version that builds zfec packages, added a step to check that the package cibuildwheel just built is actually usable, and did some manual testing on Windows and macOS. Finally, re-running Tahoe's test suite on GitHub Actions has confirmed that this time zfec is usable.

I published zfec 1.5.4 on 2020 October 15, but it turned out that wheel package for Windows + Python 2.7 was broken. Tahoe-LAFS CI failed to use zfec-1.5.4, with this error message: ``` zfec: None [(<type 'exceptions.ImportError'>, 'DLL load failed: %1 is not a valid Win32 application.', ('d:\\a\\tahoe-lafs\\tahoe-lafs\\.tox\\py27-coverage\\lib\\site-packages\\zfec\\__init__.py', 13, '<module>', 'from ._fec import Encoder, Decoder, Error'))] ``` (Seems that those error messages when CI was restarted.) [This](https://github.com/tahoe-lafs/zfec/issues/34) is the corresponding issue on zfec's tracker. I went ahead and deleted zfec 1.5.4 wheel files packaged for Windows from PyPI, in order to avoid further CI disruption. I've uploaded zfec 1.5.5 to pypi today (2020 November 12), which has been tested a little more. I updated cibuildwheel version that builds zfec packages, added a step to check that the package cibuildwheel just built is actually usable, and did some manual testing on Windows and macOS. Finally, re-running Tahoe's test suite on GitHub Actions has [confirmed](https://github.com/tahoe-lafs/tahoe-lafs/pull/862/checks?check_run_id=1390804176) that this time zfec is usable.

Sign in to join this conversation.