-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OS X test for Tk availability doesn't work #61698
Comments
If I run: $ python -mtest.test_tk I get a skip, after speaking with people familiar with OS X, it appears that the condition for the skip uses old Carbon APIs, which are totally deprecated under 64-bit. Attached is a patch which should work. |
The test for the condition was added to solve the problem reported in bpo-8716. The Tk crash for test_ttk_guionly reported there still occurs on a current 10.8 system with the Apple-supplied Cocoa Tk under the same conditions, that is, when running the tests from a process without a window manager connection, like an ssh or buildbot process where the user is not also currently logged in as the main "GUI user". And the skip test code in question does prevent that crash. The skip test also works correctly when using a 64-bit framework Python build (./configure --enable-framework), i.e. it does not skip the tests in a normal terminal session. A side effect of a framework build is that the Python interpreter runs within an OS X app bundle, which gives it magic GUI powers. But if run from a non-framework (standard unix) build, the tests are skipped with a "cannot run without OS X gui process" skip although stubbing out the check, as your patch does, shows that test_tk and test_ttk_guionly appear to run without error. So it seems that the skip test is too restrictive but it shouldn't be unilaterally deleted. |
Hi Ned, It seems from your comment that you didn't read the patch. Alex added a simpler check via launchctl, rather than by framework symbol groveling :). He didn't remove the check. It should be functionally identical to what's there now, but much shorter and without having to depend on ctypes. -glyph |
Um, yes, my tired eyes did skip over those added lines. Thanks, Glyph, and sorry, Alex. While the suggested change solves the issue for the non-framework build case, it appears to introduce new problems. For one, with the current skip test, it is possible to run the tests from a buildbot or ssh process as long as the user name is logged in. That no longer works with the proposed change. Also, "launchctl managername" does not appear to be available on releases prior to 10.6, releases we still support. |
Granted, the current test is a kludge. We could make it a bigger kludge by trying launchctl first and if it fails move on to the current ctypes-based tests. Any better options? |
A small helper program that does the equavalent of this should also work: import Cocoa
Cocoa.NSWindow.alloc().initWithContentRect_styleMask_backing_defer_(((10, 10), (100, 100)), 0, 0, 0) If this code raises an exception you cannot create windows, if it doesn't you can. This doesn't actually show the window and shouldn't mess up the users desktop when running the testsuite interactively. |
Wouldn't it be better to check for the actual problem, that is use subprocess to start a small Tcl script that creates a window and check if that crashes? That way the code for disabling the test doesn't have to try to guess whether or not Tk will crash in the current environment, and tests won't get skipped when the Tk folks get their act together and don't crash when the window manager isn't available. |
Yes, this sounds great. Doing it with Tcl means that we're not invoking any of the problematic code in question. It sounds like this check could be done on other platforms as well, in lieu of looking for e.g. $DISPLAY. If a tcl script can make tk windows, so should a Python script be able to. |
The attached patch start wish and stops it by sending the 'exit' command. With the patch I can run the tk tests without getting a skip. I cannot easily test if the patch also does the right thing on buildbots, but have high hopes. I did check that just starting 'wish' on a machine where I don't have console access causes a crash (OSX 10.5, nobody on the console, I logged on through SSH). Open issues with my patch:
|
To respond to my own message: running a small Tcl script is not good enough, the process environment of python itself is also important. In particular, GUI frameworks only work from inside an application bundle (or by using some undocumented private APIs) and that's why the Tk tests cannot work on OSX without installing. BTW. I just verified that MacOS.WMAvailable() works just fine in 64-bit processes (python 2.7 on OSX 10.8), and according to the header files the API functions used in its implementation (and the corresponding python code in 3.x) are not deprecated. |
(See also bpo-18604 which has refactored this area.) |
Some IRC discussion about what contributors should do while this is unresolved, and the bigger plan for comprehensively addressing this: 01:53 < ned_deily> jesstess, saw your nosy on bpo-17496. Beware that it's really a can of worms and definitely was misclassified as easy. Lots of edge cases, some not discussed in the issue. |
Just to note, this remains a PITA. To run gui tests on macOS from a terminal window seems to require commenting out the SetFrontProcess() call. A better replacement is needed as noted in the previous discussion, as well this call was deprecated in OS X 10.9 (though has not yet been removed as of this writing). In the interim, is there a precedent for adding another command line option to the 'test' module, e.g. '--forcemacgui' so that people who want to can run those tests from a clean checkout? |
Do the tests work properly from an installed python framework? That doesn't immediately help with the normal way of running tests, but might point to a way forward. The major difference with normal installs is that the python interpreter is started in a minimal .app bundle, which leads to better behaviour of Apple's GUI frameworks. |
The code is now in cpython/Lib/test/support/__init__.py Lines 247 to 269 in 23d0371
|
It might be worthwhile to check if using the output of |
We're not manipulating anything, so it seems to me we can safely use the legacy command to query the manager name. |
Quoting Ned:
IIRC, we don't officially support 10.6 anymore. |
Not in CI at least. Anyone supporting old OS versions can keep using the old check, MacPorts already carries a number of patches to support ancient versions of macOS. |
Something like #118390 should work; if |
…pythonGH-118390) (cherry picked from commit ce740d4) Co-authored-by: Erlend E. Aasland <erlend@python.org>
…pythonGH-118390) (cherry picked from commit ce740d4) Co-authored-by: Erlend E. Aasland <erlend@python.org>
I believe we can now close this. Thanks to everyone involved. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: