WIP, MAINT: MacOS wheels 12.0 target #150
Conversation
|
No current intention to backport this one, I'll work on a separate change for the distribution file problem that we'd likely want to backport for a |
|
CI says:
Not sure we should really have that set read-only anyway.. this seems like a clear use case where overriding is desired. |
tylerjereddy
changed the title
tylerjereddy
force-pushed
the
treddy_use_deploy_target_macos_12
branch
from
52bff5f
to
d72469b
Compare
|
Ok, trying to make that var writeable now.. |
|
This didn't work yet, wheels are still named like: |
|
https://github.com/multi-build/multibuild/blob/041625d47880e11ae3d2333874027e749b35fa72/osx_utils.sh#L489 should be fixed to not overwrite |
|
I mean not overwrite if the value does not start with |
|
Ah ok, so we need an upstream fix first. That's ok, I can try to help there if needed. |
* only overwrite MACOSX_DEPLOYMENT_TARGET environment variable when it contains the "10.x" version string * motivation is to allow sensibel overrides as in: MacPython/scipy-wheels#150 * note that I have not tested this yet, but am open to making revisions of course
|
I took a shot at the multibuild adjustment in the cross-linked PR, still untested though. |
* `universal2` wheels should now target MacOS 12.0+ using the approached described upstream: multi-build/multibuild#444 (comment) * fix the renaming of MacOS arm64 thin wheels to use the same approach instead of my previous manual bash commands * note that, confusingly, `MACOSX_DEPLOYMENT_TARGET` is also used in `env_vars.sh` and in `azure-posix.yml`, so we should double check the CI logs before merging to make sure that `pip` named the wheels correctly/we get the desired overrides for the cases touched here
* point to the multibuild feature branch here: multi-build/multibuild#446 * trying to see if this will allow override of the MACOSX_DEPLOYMENT_TARGET as intended
tylerjereddy
force-pushed
the
treddy_use_deploy_target_macos_12
branch
from
b57d085
to
d447df4
Compare
|
I pushed a commit to point this PR at least temporarily at my It should at least tell us if the thin and universal2 wheels get properly renamed with that upstream change, rather than losing an overnight testing period. |
|
CI is passing but this looks wrong, i.e.,
I think at this stage I'm going to have to pursue more manual wheel renaming until things are actually working upstream with |
* until an upstream multibuild solution is ready, "manually" rename `universal2` wheels to require MacOS version `12.0` minimum in a manner similar to what we are doing for the thin arm64 mac wheels * based on the analysis of universal2 wheel names in logs: MacPython#150 (comment) and recent nightly uploads: https://anaconda.org/scipy-wheels-nightly/scipy/files# look like we want to move from `10_9` to `12_0` universal2 file names * we should definitely check the logs to make sure this works, probably by looking at what filename gets targeted by the pip install command in the `Install wheel and test` stage for `universal2` CI runs (the `mv` command is verbose and should also print out the renamed file)
|
No longer needed as we don't do |
Fixes #148
universal2wheels should now target MacOS 12.0+using the approached described upstream:
Building thin arm64 wheels for MacOS 12+ multi-build/multibuild#444 (comment)
fix the renaming of MacOS arm64 thin wheels to use
the same approach instead of my previous manual bash
commands
note that, confusingly,
MACOSX_DEPLOYMENT_TARGETisalso used in
env_vars.shand inazure-posix.yml, sowe should double check the CI logs before merging to make
sure that
pipnamed the wheels correctly/we get the desiredoverrides for the cases touched here