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 Issue8716.  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.

> 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?

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:

* The check uses whatever version wish is on the PATH, which may or may
  not be related to the version of Tk that python is linked to. 

  It might be better to explicitly use /usr/bin/wish, as that one is
  known to be native port of Tk (not X11) and is known to crash. 

* Not tested if the patch causes a Skip when running tests without 
  GUI access.

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 Issue18604 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 Issue17496.  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.
03:01 < jesstess> ned_deily: can you update the ticket with edge cases not yet discussed? The issue is making life hard for some of our interns, so I'd love to see some progress on it.
03:02 < jesstess> ned_deily: I also found ronaldoussoren's conclusions hard to follow. I think a re-statement of what the best solution for the problem is would be really helpful, if you have opinions on it.
03:04 < ned_deily> jesstess, can you say how it is causing problems?
03:08 < jesstess> ned_deily: They are working on Tkinter tickets, and their primary development platform happens to be OSX, where the tests are getting skipped. One has set up a Linux VM already, which is fine, but it's a confusing issue to hit for new contributors and they also want to have the confidence that changes and new tests pass on OSX before submitting patches for review.
03:09 < ned_deily> jesstess, OK.  Alas, Tk is a bit of a problem on any platform and it's pretty much a mess on OS X.
03:15 < ned_deily> jesstess, Currently, there are three different variants of Tk in use on OS X.  And the most commonly used variant, the Cocoa Tk 8.5, is still relatively new and has had major bugs (still present in the version shipped by Apple in OS X) and has variations from minor release to minor release.
03:20 < ned_deily> jesstess, The plan is to make things a lot easier to test by making it easier to use a custom-built Tk for OS X.  In the meantime, there really is no easy way around things.  Fixing #17496 by  itself won't allow testing on OS X. 
03:20 < ned_deily> jesstess, For the time being, I would suggest just testing as best as possible on whatever platforms one can and submitting the patches.

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.