Conversation
|
Let's see what fails with a simple update. |
e91ab61 to
9779375
Compare
|
Could you update the pypy tarballs on macos to 7.3.11, it hopefully will solve the appveyor failure (macOS x86_64) |
9779375 to
04c45bd
Compare
|
It seems the appveyor 10.14 image falls afoul of PyPy issue 3880. There is a 10.15 Catalina appveyor image. Would it be acceptable to update or are there reasons to stay with 10.14 Mojave? Github Actions has deprecated all 10.x images. Note this is just for the platform to build the wheels, |
|
That would just be for our tests; downstream projects will stop working unless they also update to a 10.15 image too if we make this change. IMO, that's fine, but I don't feel strongly about it if someone else does. (Also IMO, PyPy should have a way to release patch releases that are separate from minor releases for these sorts of fixes ;) ) |
|
I'd also be okay to update to (at least) MSVC 2017+ for all examples - we've been dropping 2015 support elsewhere (pybind11, scikit-build) as GHA dropped support a while ago (And Python 3.7+ really should use 2017+ anyway, and it works for older ones too) |
I also think that's fine. |
|
CI is passing |
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
4cac35e to
5dab79d
Compare
.github/workflows/test.yml
Outdated
| output-dir: wheelhouse | ||
| env: | ||
| CIBW_ARCHS_MACOS: x86_64 universal2 arm64 | ||
| CIBW_SKIP: pp*-macosx_arm64 |
There was a problem hiding this comment.
Hmmm. on further consideration this does seem a little like a footgun - many people will have cross-compilation written into their configs, which will fail when this PR is added. Can we perhaps provide a softer failure on macOS when pp*_arm64 is erroneously selected on x86_64?
There was a problem hiding this comment.
e.g. when we attempt to build pp-arm64 on x86_64, we print-
warning: pp38-macosx_arm64 was selected but can't be built on this architecture (x86_64). Deselect these builds using CIBW_SKIP=pp*-macosx_arm64 to remove this warning.
I realise this is a special case, but I expect many people to hit a failed build otherwise.
On this other hand, we could say that we'd rather error out for consistency. But since our example configs have included this since arm64 support was added, it's gonna hit a lot of people.
There was a problem hiding this comment.
We could even downgrade that from a warning to a notice, since there's no real problem with not having skipped pp*_arm64.
There was a problem hiding this comment.
Actually, since we don't support pypy cross compilation, I don't even know if we need a notice - it should simply not be a selectable option on a non-native platfrom, IMO, unless we add cross compilation.
There was a problem hiding this comment.
I went with @henryiii proposal to filter out this configuration. Tests were updated to check this, let's see CI results.
There was a problem hiding this comment.
I'd still be in favour of a notice, since it's the only build identifier that's not selectable in this way.
want to discuss the common failure that this is going to introduce when users have enabled cross-compilation
|
|
Co-authored-by: Joe Rickerby <joerick@mac.com>
33c442a to
008e3dd
Compare
008e3dd to
110c748
Compare
Add PyPy macOS arm64
Cross compilation is not supported.
fixes #1369