macOS Wheels #988
macOS Wheels #988
Conversation
On macOS, mkdtemp() returns a not fully-resolved path
3.5 is broken in some important ways — seems to want specific GCC version and TLS is b0rked for pip & setuptools
|
I think we can leave out Python 3.5, probably we will drop support for it this year. Thanks! |
| LIBGIT2: "${{ github.workspace }}/libgit2/env" | ||
| LDFLAGS: "-Wl,-rpath,'${{ github.workspace }}/libgit2/env/lib'" | ||
| run: | | ||
| python3 setup.py bdist_wheel |
There was a problem hiding this comment.
FTR the recommended way of doing this is something like pip wheel --no-deps -w dist .
There was a problem hiding this comment.
Same outcome though afaik?
| libgit2: ['maint/v0.99'] | ||
| py: | ||
| - ver: '3.6' | ||
| release: '3.6.8' # last Python.org binary release |
There was a problem hiding this comment.
FTR here's a way to select the concrete "patch" version intelligently: https://github.com/amol-/dukpy/blob/54699a3/.travis.yml#L56-L109
There was a problem hiding this comment.
Thanks - I need to select the last version available as a binary release from Python.org, not the latest patch version though. I don’t understand why they’re not built automatically, but they’re not.
There was a problem hiding this comment.
Ah, re-reading, it does that, yes! Not sure it’s a big deal for us atm - we’re not typically using cutting edge CPython features
There was a problem hiding this comment.
Yep. Sometimes they release 3.6.8 for Linux, but stop at 3.6.6 for macOS. so this is something that my script accounts for. But yes, it shouldn't matter much. OTOH when you do exit-checks after the build but before publishing the artifacts, it may make sense to run tests on the recent version.
/me needs to find time and contribute that to cimultibuild...
Add macOS wheels into CI, using Github Actions macOS support.
Libgit2
Builds against
maint/v0.99to match appveyor & travis, but it's configured as a matrix so can easily test against releases/branches/etc if appropriate. Not sure if we should be doing a "release" build-DCMAKE_BUILD_TYPE=Release(orRelWithDebugInfo), but it matches the other environments atm.Python 3.5
This was in the plan, but I think the Python.org 3.5.4 release was built using an old version of GCC instead of Clang, and it's not in the CI environment by default. I can dig further, or switch to the build of Py3.5 used by GH Actions (which is macOS 10.13+ only), or we just leave it out.
PyPi
Haven't set it up to push to PyPi on release tags, but that's easily done using eg: gh-action-pypi-publish once secrets are configured.