Passing arch to the nix install script and adjusting brew libs + use macos-14 to build if needed

[jmarrec]

The commit descriptions provide more info.

[mayeut]

@jmarrec, why the change from always using universal2 installers on arm64 ?

[jmarrec]

I cannot properly link a c++ executable to it if using the universal installer. Libpython.dylib reports mach-o x64

[mayeut]

that seems like a different issue. universal2 installer provides dual arch (x86_64 & arm64). Do you have a repro for this ?

[jmarrec]

Not that simple to provide a MCVE, but I've experienced it in a (large) project that uses CMake and CPack for packaging, and which redistributes the python dylib.

Linking is ok, the issue is when executing it. It refuses to launch it due to code signature I think.

codesign --verify --deep --verbose Python
Python: invalid Info.plist (plist or signature have been modified)
In architecture: arm64

[jmarrec]

@mayeut here is a MCVE repro: https://github.com/jmarrec/test-Github-Actions/actions/runs/9446808318/job/26017370106

It's not impossible that this could be the issue: https://stackoverflow.com/questions/58997650/trying-to-codesign-a-mac-osx-app-but-when-i-check-it-i-get-pharo-app-invalid

The SO post mentions that codesign behaves differently when you have a library/exe that starts with an uppercase, and the resolved python library is Python in this case. And I think that lib is codesigned to begin with, while when you force build it isn't.

Anyways, the program links, but can't be executed.

https://github.com/jmarrec/test-Github-Actions/actions/runs/9446808318/job/26017370106#step:7:15

And the relevant build warning at https://github.com/jmarrec/test-Github-Actions/actions/runs/9446808318/job/26017246804#step:6:2196

---

And here is a run with my fork for setup-python, which uses my fork of python-versions where I force build the python package on mac

https://github.com/jmarrec/test-Github-Actions/actions/runs/9446912815