Contents
On OSX, two different types of Python Builds exist: a regular build and aframework build. In order to interact correctly with OSX through the nativeGUI frameworks you need a framework build of Python.At the time of writing themacosx andWXAgg backends require aframework build to function correctly. This can result in issues fora python installation not build as a framework and may also happen invirtual envs and when using (Ana)Conda.From Matplotlib 1.5 onwards themacosx backendchecks that a framework build is available and fails if a non frameworkbuild is found. WX has a similar check build in.
Without this check a partially functional figure is created.Among the issues with it is that it is produced in the background andcannot be put in front of any other window. Several solutions and workarounds exist see below.
If you are on Python 3, usevenvinstead ofvirtualenv:
python-mvenvmy-virtualenvsourcemy-virtualenv/bin/activate
Otherwise you will need one of the workarounds below.
If you are using pyenv and virtualenv you can enable your python version to be installed as a framework:
PYTHON_CONFIGURE_OPTS="--enable-framework"pyenvinstallx.x.x
The default python provided in (Ana)Conda is not a frameworkbuild. However, the Conda developers have made it easy to installa framework build in both the main environment and in Conda envs.To use this install python.appcondainstallpython.app andusepythonw rather thanpython
Unfortunately virtualenv creates a nonframework build even if created from a framework build of Python.As documented above you can use venv as an alternative on Python 3.
The issue has been reported on the virtualenv bug trackerhere andhere
Until this is fixed, one of the following workarounds can be used:
PYTHONHOME Function¶The best known work around is to use the nonvirtualenv python along with the PYTHONHOME environment variable.This can be done by defining a function in your.bashrc using
function frameworkpython { if [[ ! -z "$VIRTUAL_ENV" ]]; then PYTHONHOME=$VIRTUAL_ENV /usr/local/bin/python "$@" else /usr/local/bin/python "$@" fi}This function can then be used in all of your virtualenvs without having tofix every single one of them.
With this in place you can runframeworkpython to get an interactiveframework build within the virtualenv. To run a script you can doframeworkpythontest.py wheretest.py is a script that requires aframework build. To run an interactiveIPython session with the frameworkbuild within the virtual environment you can doframeworkpython-mIPython
PYTHONHOME Script¶An alternative work around borrowed from theWX wiki, is to use the nonvirtualenv python along with the PYTHONHOME environment variable. This can beimplemented in a script as below. To use this modifyPYVER andPATHTOPYTHON and put the script in the virtualenv bin directory i.e.PATHTOVENV/bin/frameworkpython
#!/bin/bash# what real Python executable to usePYVER=2.7PATHTOPYTHON=/usr/local/bin/PYTHON=${PATHTOPYTHON}python${PYVER}# find the root of the virtualenv, it should be the parent of the dir this script is inENV=`$PYTHON -c "import os; print(os.path.abspath(os.path.join(os.path.dirname(\"$0\"), '..')))"`# now run Python with the virtualenv set as Python's HOMEexport PYTHONHOME=$ENVexec $PYTHON "$@"With this in place you can runframeworkpython as above but will need to add this scriptto every virtualenv
In additionvirtualenv-pythonw-osxprovides an alternative workaround which may be used to solve the issue.