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?

Horselaugh

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.

Medical

All of my python versions are installed by penv (i.e. env PYTHON_CONFIGURE_OPTS="--enable-framework" pyenv install 3.7.4. I'm updating the question to resolve that ambiguity. None of the tools involved are installed by brew. What about anaconda would provide me with something that compiling python myself (via pyenv) with --enable-framework would not? – Horselaugh

I should also note that this doesn't answer the core question, which is about what wxPython actually needs in order to run successfully. – Horselaugh

The underlying issue is described at wxpython [wiki.wxpython.org/wxPythonVirtualenvOnMac] and even they don't know for sure what the exact issue is. Their answer: The reason is because some 3rd party tools like PyInstaller might require CPython installation be built with --enable-framework. You've tried their answe to go around it and still doesn't work. The solution posted is how I've handled spending less time on this deep rooted bug. – Medical

A possible trigger might be that some code uses old-style python class inheritance inside some pyd (python version of dll) files or a mix of using older wxpython (e.g. v3). As wxpython v3 support is dropped in 2017.... its guessing. If you're not bound to wxpython my suggestion would be PyQt5 or PySide. It produces your gui code for you. – Medical

Yes, that's one of the pages I read before posting this. Your quote from the page is incomplete. The full quote is: "The reason is because some 3rd party tools like PyInstaller might require CPython installation be built with --enable-framework. What you need to do is run $ env PYTHON_CONFIGURE_OPTS="--enable-framework" pyenv install 3.x.x in your terminal." ... which is what I've done. – Horselaugh

Thanks for the suggestions of other frameworks. Part of the point of using a portable framework is to make it portable.. and given the complex installation problems it seems like wxPython doesn't really fit that descriptor. – Horselaugh

Indeed. I didn't go this far as you did with src/_app.i due to limited time for bug seeking and I already was working cross-platform with anaconda. So the easiest thing to do for me was to welcome it on the mac. Likely 2020 Q2 a new Mac and I'll give then wxPython another shot. I'll post then my findings. – Medical

@Medical your link to the VirtualenvOnMac wiki entry has an erroneous ] character at the end of it. Working link is https://wiki.wxpython.org/wxPythonVirtualenvOnMac – Nelson

Answer 2

You mention "virtualenv". Is that the actual virtualenv package or just what you are calling the pyenv instance? If the former then try python -m venv instead. The virtualenv package still hides the framework-ness of the parent Python, even after all these years. The venv package is included with Python3 and is a much better/simpler implementation of the concept.

Oleaceous

As explained in the question, it's the virtualenv and virtualenv-wrapper plugins to pyenv. I can't say with certainty how that's implemented in the back-end by pyenv. – Horselaugh