gh-123155: On Darwin, fall back to X if DISPLAY is set

[smontanaro]

This PR allows the test suite to fall back to use X on MacOS is DISPLAY is set. Maybe a better fix would be to allow the user to specify which GUI interface to use, but this works well enough for me, and I never have the requisite Mac GUI server running anyway.

• Issue: Unit tests on Mac should fall back to use X if DISPLAY is set #123155

[smontanaro]

@ronaldoussoren Can you take a look? It seems better than the status quo to me.

Also, note that running the test suite with TESTOPTS=-ugui and this patch does allow the tkinter and ttk tests to run, but the ttk test fails for reasons I'm unqualified to assess.

[ronaldoussoren]

and I never have the requisite Mac GUI server running anyway.

What do you mean by this? "The requisite Mac GUI server" is the macOS UI. Do you only test on a headless Mac where you're logged in on using SSH?

I'm -1 on falling back like this, any GUI tests on macOS should use the default UI system for that platform. Regardless of that, using X11 also requires a non-standard build of Tcl/Tk to actually use an X11 display server

[smontanaro]

I only ever run on my M1 MacBook Pro. Tkinter tests have never worked for me because of this "no server" thing. I don't do framework builds because several other tests never pass.

[ronaldoussoren]

I only ever run on my M1 MacBook Pro. Tkinter tests have never worked for me because of this "no server" thing. I don't do framework builds because several other tests never pass.

Does Tkinter work for you outside of tests?

Apple's GUI frameworks assume they are invoked in code bundles into an .app bundle, which the framework arranges for. That said, I haven't verified this for years it may be that this is still needed, and on the other hand Tk might use one of the private APIs in Apple's libraries to enable running outside of a framework.

[smontanaro]

Good question. otool tells me I'm using Tcl/Tk from Homebrew. I'd never even looked before, given that I hadn't explicitly pointed to Homebrew. (I just thought I was getting whatever came from Apple.) That's almost certainly why I'm failing without my proposed fallback. I guess I'm getting it without any specific configure options because I need /opt/homebrew/... for other bits Apple doesn't provide.

--with-openssl=/opt/homebrew/Cellar/openssl@3/3.3.1
--with-readline=readline
LIBREADLINE_CFLAGS=-I/opt/homebrew/Cellar/readline/8.2.10/include
LIBREADLINE_LIBS='-L/opt/homebrew/Cellar/readline/8.2.10/lib -lreadline'
LIBB2_CFLAGS='-I/opt/homebrew/include'
PKG_CONFIG=/opt/homebrew/Cellar/pkg-config/0.29.2_3/bin/pkg-config
GDBM_CFLAGS=-I/opt/homebrew/include
GDBM_LIBS='-L/opt/homebrew/lib -lgdbm'

The question is: Where is the Apple-provided(?) Tcl/Tk supposed to live? I thought they were installed by default. I can't find a promising .dylib file in the default spaces on my machine. I do have /System/Library/Tcl which contains a bunch of Tcl/Tk-ish looking .dylib files, but no actual Tcl or Tk libraries as I would expect.

% find /System/Library/Tcl -name '*.dylib'
/System/Library/Tcl/sqlite3/libtclsqlite3.dylib
/System/Library/Tcl/8.5/tdom0.8.3/libtdom0.8.3.dylib
/System/Library/Tcl/8.5/thread2.6.6/libthread2.6.6.dylib
/System/Library/Tcl/8.5/tls1.6.1/libtls1.6.1.dylib
/System/Library/Tcl/8.5/tclAE2.0.5/libtclAE2.0.5.dylib
/System/Library/Tcl/8.5/tnc0.3.0/libtnc0.3.0.dylib
/System/Library/Tcl/8.5/vfs1.4.1/libvfs1.4.1.dylib
/System/Library/Tcl/8.5/Tclxml2.6/libTclxml2.6.dylib
/System/Library/Tcl/8.5/xotcl1.6.6/libxotcl1.6.6.dylib
/System/Library/Tcl/8.5/tbcload1.7/libtbcload1.7.dylib
/System/Library/Tcl/8.5/Memchan2.2.1/libMemchan2.2.1.dylib
/System/Library/Tcl/8.5/Trf2.1.4/libTrf2.1.4.dylib
/System/Library/Tcl/8.5/expect5.45/libexpect5.45.dylib
/System/Library/Tcl/8.5/itcl3.4/libitcl3.4.dylib
/System/Library/Tcl/8.5/itk3.4/libitk3.4.dylib
/System/Library/Tcl/8.5/Mk4tcl2.4.9.7/libMk4tcl2.4.9.7.dylib
/System/Library/Tcl/8.5/Tclxslt2.6/libTclxslt2.6.dylib
/System/Library/Tcl/8.5/Ffidl0.6.1/libFfidl0.6.1.dylib
/System/Library/Tcl/8.5/Tcldom2.6/libTcldom2.6.dylib
/System/Library/Tcl/8.5/tclx8.4/libtclx8.4.dylib
/System/Library/Tcl/8.5/Tktable2.10/libTktable2.10.dylib
/System/Library/Tcl/8.5/tcldomxml2.6/libtcldomxml2.6.dylib
/System/Library/Tcl/8.5/Tclexpat2.6/libTclexpat2.6.dylib

[ronaldoussoren]

Good question. otool tells me I'm using Tcl/Tk from Homebrew. I'd never even looked before, given that I hadn't explicitly pointed to Homebrew. (I just thought I was getting whatever came from Apple.) That's almost certainly why I'm failing without my proposed fallback. I guess I'm getting it without any specific configure options because I need /opt/homebrew/... for other bits Apple doesn't provide.

Getting Tcl/Tk from Homebrew shouldn't matter, that should just be the same backend for Tk as we use in our installers and that doesn't support X11.

But that doesn't answer my question. Does "python3 -m tkinter" show a GUI? (using the command to invoke your build of python).

If that works, and likewise if our Tkinter and IDLE tests work with your patch, there's something wrong with the code that checks if a GUI can be used.

Could you check if #118390 fixes the issue for you?

The question is: Where is the Apple-provided(?) Tcl/Tk supposed to live? I thought they were installed by default. I can't find a promising .dylib file in the default spaces on my machine. I do have /System/Library/Tcl which contains a bunch of Tcl/Tk-ish looking .dylib files, but no actual Tcl or Tk libraries as I would expect.

The system provided Tck/Tk live in /System/Library/Frameworks/{Tcl,Tk}.framework and the filenames for the shared libraries for Tcl and Tk themselves don't end ".dylib" because they are shipped as framework. That said, on macOS 11 or later you won't find the actual shared libraries in the filesystem due to how Apple ships shared libraries in recent versions of macOS.

That said, the system provided Tcl/Tk is not relevant because we don't support that ancient version of Tk due it being fairly buggy.

[smontanaro]

But that doesn't answer my question. Does "python3 -m tkinter" show a GUI? (using the command to invoke your build of python).

Sorry, got carried away in a rabbit hole full of .dylib files...

Indeed, ./python.exe -m tkinter does work (on main branch):

Could you check if #118390 fixes the issue for you?

Yes it does.