@python/macos-team

The GA does not run the tests with --enable-framework, so how can we test the change?

Could you explain what you mean?

The GA does not run the tests with --enable-framework, so how can we test the change?

Could you explain what you mean?

I am not the PR author, but to try to explain this: the proposed changes to getpath.c affect code which is only compiled when WITH_NEXT_FRAMEWORK is defined, which is only the case when the configure script is run with --enable-framework. But the GitHub Actions CI for macOS does not do this, so the proposed changes have not been fully tested by the CI.

A relevant issue for this is #59703, which contains an ancient patch that uses basically the same solution (but is outdated otherwise).

@ned-deily : is this something you can easily test on a number of macOS versions? I can currently only test on macOS 14 and 13, and I'd prefer to have test results on at least one version before 11.0 before changing the way we merge this.

Will do

To test, I cherry-picked the PR to the current head of 3.12 and built a current python.org-style 10.9+ universal2 installer. I then installed on and ran the usual test suite on: macOS 14.1 (Apple Silicon and Intel), macOS 11 (Apple Silicon), macOS 10.13 (Intel), and macOS 10.9 (Intel). I did not notice any regressions from the 3.12.0 release. So, while not a comprehensive test and not testing any effects on embedded uses, I think we could go ahead with this for 3.13.

FTR, this PR introduced a regression for older macOS releases that was corrected by #112309. Both PRs were included in 3.13.0a2.