Avoid falling back to deprecated Apple-supplied Tcl/Tk 8.5 on macOS builds for 3.8, 3.9, and 3.10

[ned-deily]

The Apple-supplied Tcl and Tk frameworks on macOS releases have been deprecated and not updated in years. They are ancient 8.5.9 versions that have many known critical problems and should not be being used by anyone at this point. As of Python 3.11, we no longer fall back to using the system version if no other Tcl/Tk libraries are found and simply skip building the _tkinter extension module in that case. But we still do for older branches that are in the security-fix-only phase of their life, currently 3.8, 3.9, and 3.10, and this misbehavior can cause CI and/or buildbot tests for these branches to fail.

Since properly running GUI tests are difficult in this environment anyway, the attached PR removes the fallback check in setup.py for the system-supplied Tcl/Tk on macOS. For these branches, no other behavior is changed: it is still possible to specify locations for Tcl/Tk headers and libs using the --with-tcltk-includes= and --with-tcltk-libs= ./configure options and, on 3.10, through the use of pkg-config. (Starting with 3.11, the --with-tcltk-* options have been removed in favor of generalized *_CFLAGS= and *_LIBS= ./configure options along with full pkg-config support.)

Linked PRs

• [3.10] gh-115436: Avoid falling back to deprecated Apple-supplied Tcl/Tk 8.5 on macOS. #115437
• [3.9] gh-115436: Avoid falling back to deprecated Apple-supplied Tcl/Tk 8.5 on macOS. #115438
• [3.8] gh-115436: Avoid falling back to deprecated Apple-supplied Tcl/Tk 8.5 on macOS. #115439

[encukou]

Do these frameworks have security problems, though? If not, I'm not sure this change is appropriate for security branches. (See your previous comment: #97032 (comment))
OTOH, someone who builds Python from source can probably live with tkinter disappearing.

If we do this we might want to

• mention the change in a Notable Changes in 3.8.19 section at the end of What's New
• perhaps give users a way to restore the previous behaviour?

Other possible options I can see:

• configure the affected buildbot to use a newer Tcl/Tk
• skip the tests on the affected buildbot

[ned-deily]

After further analysis, it looks like the failure is more limited than I originally thought: there appears to be only one test case that exhibits the crash behavior (and was reported earlier) and the crash behavior is limited to linking with specific, non-current versions of the macOS system Tcl/Tk 8.5. I can reproduce it on the most recent security update of macOS 12.7 (12.7.3, the failing buildbot is running 12.7.2) and also macOS 11.7.10 (which is no longer being updated by Apple). It doesn't seem to be an issue with the macOS system Tcl/Tk 8.5 in current updates of either macOS 13 or 14 (the latest macOS release). Given that this is very much an edge case that few, if any, users will run into, a simpler workaround is just to skip the failing test case if the GUI resource is not available.