Pin python brew installation to 3.10 during MacOS Intel Cirrus Build

[confused-Techie]

This PR is a response to the recent consistent failure of MacOS Intel Builds on Cirrus.

The fix was helpfully pointed out by @DeeDeeG over on PR #383 and that fix has just been applied here.

All thanks goes to them for identifying and finding the solution.

[DeeDeeG]

I expect this problem (Homebrew updating their python alias to point to python@3.11 ~yesterday) to affect Apple Silicon equally as well. (It is probably a new issue, besides the thing that has been affecting the macOS signing PR.)

Also, not sure if python@3.10 Homebrew package installs a python3 binary anywhere, maybe just a python3.10 binary? (The "alias" python package definitely sets up a python3 binary, but pinning a specific version bypasses that, I think?) So, maybe we have to do something about that.

(We might end up specifying ln -s path/to/python3.10 /usr/local/bin/python or something like that. I'd prefer if we don't have to hard-code the "3.10" in multiple spots, but getting CI working even if it's not perfectly D.R.Y. might prove more of a priority.)

It's late where I am, so I'll have to look into it tomorrow, if someone else hasn't beaten me to it. (Or maybe this will work as-is? I won't see it until tomorrow, as I'm going to sleep now. Good night!)

[DeeDeeG]

Well, it turns out I am still up for the moment... (But now I really should sleep.)

macOS Apple Silicon

Weirdly enough the Apple Silicon job is still installing Python 3.10. I expect that's due to caching, or a base image that wasn't updated quite so recently as the intel base image, and so I expect it is just a matter of time before the Apple Silicon job faces the same issue.

I suggest that whatever solution is applied for macOS Intel should be applied for Apple Silicon as well.

macOS Intel

And yeah, this is installing a python3.10 binary, we have to do something deliberate to get it (or a python3 binary it provides at a different path), onto the PATH env var.

Cirrus log of the python@3.10 installation from the macOS Intel job (click to expand):

==> Installing python@3.10
==> Pouring python@3.10--3.10.10.monterey.bottle.1.tar.gz
==> /usr/local/Cellar/python@3.10/3.10.10/bin/python3.10 -m ensurepip
==> /usr/local/Cellar/python@3.10/3.10.10/bin/python3.10 -m pip install -v --no-
==> Caveats
Python has been installed as
  /usr/local/bin/python3.10
Unversioned and major-versioned symlinks `python`, `python3`, `python-config`, `python3-config`, `pip`, `pip3`, etc. pointing to
`python3.10`, `python3.10-config`, `pip3.10` etc., respectively, have been installed into
  /usr/local/opt/python@3.10/libexec/bin

The above shows we can symlink /usr/local/bin/python3.10 to python3 somewhere on the PATH, or we can symlink /usr/local/opt/python@3.10/libexec/bin/python3 onto the PATH.

I suppose if we set the python major/minor version as a variable we can D.R.Y. the config that way?

---

node-gyp (??)

Alternate fix?? (click to expand):

We could also resolve this in a fairly roundabout way by bumping the bundled npm we ship with ppm to npm 8.x or newer.

• Newer node-gyp (starting with node-gyp v8.0.0) has a fix for this error.
  • https://github.com/nodejs/node-gyp/blob/main/CHANGELOG.md#v800-2021-04-03
  • gyp: update gyp to v0.7.0 nodejs/node-gyp#2284
    • Fix ValueError: invalid mode: 'rU' while trying to load binding.gyp nodejs/gyp-next#83
• Newer npm has node-gyp new enough to include the fix
  • https://github.com/npm/cli/blob/v8.19.4/package.json#L101

See this PR that demonstrates how bumping ppm's bundled npm to 8.x or newer should be doable:
atom-community/apm#123

But yeah, I intend to explore that soon, as npm 6.x's implict support ends at the end of April 2023 with the EOL of Node 14. And that's kinda soon anyways, so might as well look into it. And it'd give us these various modern fixes.

[meadowsys]

I think I would rather pin it for Apple Silicon too, just to be sure

[confused-Techie]

@meadowsys you have a good point about pinning it on silicon as well so I'll address that here.

@DeeDeeG as for symlinking the path, can you see where it'd be best to do that in our script?

In the script we already run ln -s /usr/local/bin/python3 /usr/local/bin/python so could we possibly just change the first entry to 3.10? I'll probably try that in the next few minutes here just in case.

Then ideally when there's not as much concern for getting a release today we can do this properly or I'll do it now if it seems reasonable

[DeeDeeG]

@confused-Techie sure, or add /usr/local/opt/python@3.10/libexec/bin to the PATH env var, either way should work the same, I don't have a preference for which. I guess changing the existing symlinking step makes for a smaller diff.

[DeeDeeG]

I like that we can specify (and update) this in one place, instead of four! 👍

[DeeDeeG]

Just waiting for Windows CI to be green/passing, don't want to make 1 step forward 1 step back, but realistically if Windows goes red that'll be a problem for another PR anyway... So I'm going to be an approve for this soon either way.

[DeeDeeG]

Approving because:

This PR is all about (and only about) fixing Cirrus. Cirrus is now passing. (On all OSes/Arches!)

Let's go! 🚀

(Thanks for fixing this!)