What does wxPython need to run successfully?

Question

I'm trying to get wxPython to work in a pyenv-based virtualenv with the virtualenv and virtualenvwrapper plugins on MacOS. I've read several questions about making this work, but most of the answers seem to assume that I'm using the system python version, and/or only address one aspect of a broken setup. I haven't yet seen anything that explains what wxPython is checking for when it starts.

I have python 3.7 compiled by pyenv with --enable-framework.

env PYTHON_CONFIGURE_OPTS="--enable-framework" pyenv install 3.7.4

pyenv itself is installed in my homedir from a reasonably recent (within the last couple of weeks) pull from git.

To be clear, none of the tools or libraries in my Python toolchain are installed by Homebrew.

My virtualenv has access to the framework by virtue of --system-site-packages. Having access to the framework and to the display are supposedly all that's required for wxPython to work, yet I'm still getting the same error on start of any test 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.

It looks to me like everything I should need is available.

% pyenv which python3.7
/Users/matt/.pyenv/versions/3.7.4/bin/python3.7

% mkvirtualenv --system-site-packages --python python3.7 wxtest
Running virtualenv with interpreter /Users/matt/.pyenv/shims/python3.7
Already using interpreter /Users/matt/.pyenv/versions/3.7.4/Python.framework/Versions/3.7/bin/python3.7
Using base prefix '/Users/matt/.pyenv/versions/3.7.4/Python.framework/Versions/3.7'
New python executable in /Users/matt/.ve/wxtest/bin/python3.7
Also creating executable in /Users/matt/.ve/wxtest/bin/python
Installing setuptools, pip, wheel...
done.
virtualenvwrapper.user_scripts creating /Users/matt/.ve/wxtest/bin/predeactivate
virtualenvwrapper.user_scripts creating /Users/matt/.ve/wxtest/bin/postdeactivate
virtualenvwrapper.user_scripts creating /Users/matt/.ve/wxtest/bin/preactivate
virtualenvwrapper.user_scripts creating /Users/matt/.ve/wxtest/bin/postactivate
virtualenvwrapper.user_scripts creating /Users/matt/.ve/wxtest/bin/get_env_details

% python -m site
sys.path = [
    '/Users/matt/devel/wxtest',
    '/Users/matt/.ve/wxtest/lib/python37.zip',
    '/Users/matt/.ve/wxtest/lib/python3.7',
    '/Users/matt/.ve/wxtest/lib/python3.7/lib-dynload',
    '/Users/matt/.pyenv/versions/3.7.4/Python.framework/Versions/3.7/lib/python3.7',
    '/Users/matt/.ve/wxtest/lib/python3.7/site-packages',
    '/Users/matt/.pyenv/versions/3.7.4/Python.framework/Versions/3.7/lib/python3.7/site-packages',
]
USER_BASE: '/Users/matt/.local' (exists)
USER_SITE: '/Users/matt/.local/lib/python3.7/site-packages' (doesn't exist)
ENABLE_USER_SITE: True

% pip install wxPython
Collecting wxPython
[...]
Successfully installed numpy-1.18.0 pillow-6.2.1 six-1.13.0 wxPython-4.0.7.post2

The code for IsDisplayAvailable() is buried in the _core shared object library, so not particularly easy to examine. I'm not a C++ coder, and digging around in the code repository all I've been able to find so far is the docstring in src/_app.i, not the actual code.

• On Mac OS X a False return value will mean that wx is not able to access the window manager, which can happen if logged in remotely or if running from the normal version of python instead of the framework version, (i.e., pythonw.)

That list of requirements seem to be satisfied by what I have here. I don't have a pythonw binary, but as the pythonw(1) man page says:

Actually, since Python 2.5, the normal python also allows GUI access, so python and pythonw are now interchangeable.

Does anyone have an exhaustive list of what wxPython actually expects to find before it runs?

Answer 1

The error you're encountering is likely to be a "brew-hole" (a.k.a homebrew installation/compatibility issue for wxpython v3 and sometimes v4).

To test some issues that might be at hand perform the following in your pyenv:

1. python --version
2. python3 --version

How are they installed? Did you use brew?

3. If brew or any non-anaconda: uninstall all.

4. Then : reinstall python via the anaconda 2019. (xx >04) packaged version and it gives you 3.7.4 or 3.7.5 depending on what you choose.

5. reinstall via conda/pip cmd-line the required packages that are not with default install.

Anaconda "base" is your default environment.

6. Then conda create --name myenv where myenv is any name you give your environment. For example "myPythonwx408" environment.
7. cmdline: conda activate myenv

... and tada.. up you go...

If the error persist in anaconda env you can post the environment.yml file so I can recreate your environment for testing.