gh-61698: Use launchctl to detect macOS window manager in tests

[erlend-aasland]

• Issue: OS X test for Tk availability doesn't work #61698

[ronaldoussoren]

LGTM.

I'd definitely check if it works on our buildbots before committing this though, with some luck those have a setup that claims to be an Aqua session but isn't.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @erlend-aasland for commit 37eec0b 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[erlend-aasland]

Unfortunately, the sessions on the macOS CIs claim to be Aqua, so this won't work.

[erlend-aasland]

The ARM64 MacOS M1 Refleaks NoGIL PR buildbot correctly skips the tests, though.

[erlend-aasland]

OTOH, we could fix (or skip) the failing tkinter tests and go on with this PR.

[erlend-aasland]

OTOH, we could fix (or skip) the failing tkinter tests and go on with this PR.

@ned-deily, @ronaldoussoren: what do you think?

[ned-deily]

Thanks for following up on this issue, @erlend-aasland and @ronaldoussoren. It looks like this change will generally do the right thing more of the times than the previous check, i.e. it is less conservative and allows GUI tests to run in additional environments (like non-framework builds) but still guards against the worst case. I verified that it works back to 10.9 and also verified that a check is still needed: trying to run the gui tests, like test_ttk, through an ssh connection to a Mac with a current version of macOS and Tk 8.6.x without a logged-in console can cause the test process to hang and grow in size. With either the current or this new check, that doesn't happen. One could argue that Tk should handle this but we should guard against it in any case.

[erlend-aasland]

Thanks for the reviews, @ned-deily and @ronaldoussoren. Before landing, I'll create issues for the failing tests and temporarily skipping them on macOS. I'll get back on this later today.

[erlend-aasland]

The failing¹ test is already recorded by Ronald in #86673 (comment), coupled with suggested solutions.

Footnotes

1. AFAICS, there is only one failing tkinter test ↩

[smontanaro]

Can this be merged? I've been running with it applied for a while with no problems. (Would be nice if it could be backported as well.)

[erlend-aasland]

Can this be merged? I've been running with it applied for a while with no problems. (Would be nice if it could be backported as well.)

No, it breaks CI. See my earlier comment: #118390 (comment)

[smontanaro]

Can this be merged? I've been running with it applied for a while with no problems. (Would be nice if it could be backported as well.)

No, it breaks CI. See my earlier comment: #118390 (comment)

Hmmm... I suppose there's no way to use an in-memory framebuffer as the display device? (Does seem like a lot of work for CI unless someone else has already done the hard work.)

[erlend-aasland]

Hmmm... I suppose there's no way to use an in-memory framebuffer as the display device? (Does seem like a lot of work for CI unless someone else has already done the hard work.)

I merged a variant of Serhiy's suggesting for one of the failing Tk tests and synced this PR with main. Let's see how it fares now.

[erlend-aasland]

Well, test.test_ttk.test_widgets.ComboboxTest.test_identify still fails. Let's fix that as well.

[erlend-aasland]

All right, let's land this!

[bedevere-app]

GH-125392 is a backport of this pull request to the 3.13 branch.

[bedevere-app]

GH-125393 is a backport of this pull request to the 3.12 branch.