cctbx_project
cctbx_project copied to clipboard
GUI dispatchers don't seem to work on Mac
Saw a while ago on DIALS, but intermittently. It seems to have come back: https://github.com/dials/dials/issues/1460
Reproducible directly for me with conda-forge cctbx=2022.1
on macOS Big Sur 11.5.2/arm64:
$ mamba create -yp ENV cctbx
$ conda activate ENV/
$ cctbx.image_viewer
This program needs access to the screen. Please run with a
Framework build of python, and only when you are logged in
on the main display of your Mac.
In the past using pythonw
has worked for me, though have seen anecdotal reports from people saying that didn't fix it for them.
I'll take a look at this for the February 2022 (2022.2) release. It seems python.app
changed a bit.
I only really test plotting in matplotlib
and that is working.
(test) [bkpoon@eeyore:~] cctbx.python
Python 3.10.2 | packaged by conda-forge | (main, Feb 1 2022, 19:28:34) [Clang 11.1.0 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.pyplot as plt
>>> x = range(100)
>>> y = range(100, 200)
>>> plt.plot(x, y)
[<matplotlib.lines.Line2D object at 0x10fe77220>]
>>> plt.show()
It looks like the default matplotlib
backend on macOS does not need the framework build. Changing the backend to WXAgg
does trigger the same error message.
Also, I don't think cctbx.image_viewer
has been updated to be compatible with wxPython 4.1.
This also triggers it:
$ cctbx.python -c "import wx; wx.App()"
This program needs access to the screen. Please run with a
Framework build of python, and only when you are logged in
on the main display of your Mac.
I switched the Python to the one in python.app
and added your wx test to the conda-forge recipe so the February 2022 (2022.2) release should work.
Is there some way to get this fix with directly-built cctbx? Even if I run ../conda_base/bin/python.app ../modules/cctbx_project/libtbx/configure.py dials
directly with python.app
it seems to writes LIBTBX_PYEXE_BASENAME="python3.9"
into the dispatchers....
Yeah, the python.app
package was updated to use symbolic links and the path is being resolved to the actual file instead of keeping the symbolic link during the dispatcher generation.
I'll be adding the fix for the March release since it affects the conda package.