CI: Python 3.12-related fixes on Cirrus CI

[DeeDeeG]

Identify the Bug

CI is failing with Python 3.12 in Cirrus, as of #779.

(That PR fixed Python 3.12 issues in GitHub Actions, but introduced more ones in Cirrus, which we didn't catch right away, since Cirrus is currently running only once per day, on Mondays, Wednesdays and Fridays.)

Description of the Change

• Don't install setuptools on the Cirrus ARM Linux task.
  • The ARM Linux Cirrus task is actually running on Python 3.7 which still ships with distutils out of the box... and the python3 -m pip install setuptools command had been failing due to "no module named 'pip'"... We only need to add setuptools on Python 3.12 or later anyhow, and we should be able to do apt-get install python3-pip at such a time as this would be needed, if ever.
• Do brew update before running brew install on the Cirrus Apple Silicon macOS task, so that it is aware of the existence of [email protected], and can install it successfully.

These changes resolve the two Python 3.12-related issues in Cirrus (which were introduced alongside bona-fide fixes in #779, which is a PR I personally review-approved).

Alternate Designs

• We could do apt-get install python3-pip on the Arm Linux task.
  • This would be pretty pointless, unless we actually get a copy of Python 3.12 on ARM Linux, which is also kinda pointless, or would needlessly complicate our CI, IMO. Right now it's apparently using Python 3.7, which is fine, IMO.
• We could stop updating to Python 3.12 on the Apple Silicon macOS task.
  • But as a side-effect of doing brew update, some other dependencies were unexpectedly updated as well, including git and curl. This is somewhat desirable for supply-chain security in CI. It uses more CPU-time, so we should watch credit usage on the macOS tasks in Cirrus after this PR. But we're only using 14 credits (September) and 11 credits (October) lately, so we're not running too close to the 50 credit-equivalent free limit per month set by Cirrus.

Possible Drawbacks

Actually upgrading to Python 3.12 on the macOS task unexpectedly increased macOS CI time by ~3 minutes on a test run. So, we should watch credit usage, but again, we're only using 14 credits (September) and 11 credits (October) lately, so we're not running too close to the 50 credit-equivalent free limit per month set by Cirrus.

Verification Process

Triggered a cron build on Cirrus to test this, CI is passing over there and a Rolling release was generated successfully. ✅

• https://cirrus-ci.com/build/5973566382931968
• https://github.com/pulsar-edit/pulsar-rolling-releases/releases/tag/v1.110.2023110623

Release Notes

N/A (CI-only fix) but if I were to put it in a changelog it would be "Python 3.12-related fixes on Cirrus CI"

[confused-Techie]

@DeeDeeG Interestingly, I saw the same macOS failure on #763 until I reran it, then it experienced another more different failure, that I'm not seeing in Linux, and wouldn't expect to be platform dependent.

[DeeDeeG]

Off-topic: It's platform-dependent in the sense that Ubuntu ships with an older Python version and the GitHub Actions GitHub-hosted Runners go with that version for Ubuntu, but they somewhat continuously update it on macOS (and presumably on Windows as well...?).

[DeeDeeG]

Also, one can pretty much disregard CI that's surfaced in the GitHub.com UI for this PR.

The only relevant CI is Cirrus... and even that is intentionally skipping PRs, and skipping everything except for Cron builds and tag pushes, for that matter.

Check the cron build I manually set up for this to see it working in Cirrus: https://cirrus-ci.com/build/5973566382931968

Everything else is just testing the GitHub Actions stuff, this PR only changed .cirrus.yml, so failures actually showing on this PR are not related to this branch.

[confused-Techie]

Thanks a ton for getting to this one DeeDee!
LGTM and lets get these CI fixes merged