CI: skip qt, cairo, pygobject related installs on OSX on travis #18476
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
|
If you check the logs they also are not building. Is it worth adding a second commit so I move them in waves? |
|
Probably not, just the commit summary is confusing a bit, then. |
On 2020-09-12 pyqt5 replaced their wheels to have a minimum OSX version of 10.13 which caused us to fallback to trying to build pyqt5 from the tar.gz. This in turn failed (because we do not have any of the qt development libraries installed and even if we did it would take a while). We have always been installing pyside2 from wheels, but an older version (5.13.2) that has a fatal-to-us bug. However the previously published pyqt5 wheels were, despite being labeled as 10.12 actually complied against 10.13 and failed to import. This cause our test suite to decide that we did not have a valid qt binding and skip the qt tests. Now that pyqt5 is (correctly) not installing we are falling back to pyside2 and hitting the bug in pyside2 (it is reported to fixed in the next release 5.14.0 but that only has wheels for 10.13). PyGObject, pycairo, and cariocffi also do not install on OSX 10.12 This skips trying to install pycairo, pygobjoct, pyqt5, and pyside2 on OSX on travis because they all fail to install on OSX 10.12. It will make our CI marginally faster and does not move the status quo of what we were actually testing.
c9b043a to
b86725a
Compare
|
I force-pushed a commit with better comments. |
QuLogic
approved these changes
Sep 15, 2020
|
Going to merge on one approval for the CI fix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On 2020-09-12 pyqt5 replaced their wheels to have a minimum OSX version of 10.13 which caused us to fallback to trying to build pyqt5 from the tar.gz. This in turn failed (because we do not have any of the qt development libraries installed and even if we did it would take a while). We have always been installing pyside2 from wheels, but an older version (5.13.2) that has a fatal-to-us bug. However the previously published pyqt5 wheels were, despite being labeled as 10.12 actually complied against 10.13 and failed to import. This cause our test suite to decide that we did not have a valid qt binding and skip the qt tests. Now that pyqt5 is (correctly) not installing we are falling back to pyside2 and hitting the bug in pyside2 (it is reported to fixed in the next release 5.14.0 but that only has wheels for 10.13).
This skips trying to install pycairo, pygobjoct, pyqt5, and pyside2 on OSX on travis because they all fail to install on OSX 0.12. It will make our CI marginally faster and does not move the status quo of what we were actually testing.
We don't see this problem on 3.3.x because we only pin back to xcode9 on master branch via e993baf
We are catching "modern" osx on azure (where we are running a 10.15 and a "latest" in the matrix).