@@ -40,6 +40,7 @@ exist. Some of these are given here:
40
40
* The ``TKAgg `` backend doesn't require any external dependencies and is
41
41
normally always available.
42
42
* The ``QT4 `` framework ``PySide `` is pip installable.
43
+ * ``PYQT5 `` is pip installable on Python 3.5.
43
44
* The upcoming `WX Phoenix <http://wiki.wxpython.org/ProjectPhoenix >`_ toolkit
44
45
is ``pip `` installable.
45
46
@@ -59,8 +60,8 @@ I.e. to use PyQt5, you should symlink ``PyQt5`` and ``sip`` from your system
59
60
site packages directory into the environment taking care that the environment
60
61
and the systemwide install use the same python version.
61
62
62
- OSX
63
- ===
63
+ OSX Framework builds
64
+ ====================
64
65
65
66
Short version
66
67
-------------
@@ -76,28 +77,73 @@ Long version
76
77
------------
77
78
78
79
On OSX, two different types of Python Builds exist: a regular build and a
79
- framework build. In order to interact correctly with OSX through some
80
+ framework build. In order to interact correctly with OSX through the native
80
81
GUI frameworks you need a framework build of Python.
81
- At the time of writing the ``macosx ``, ``WX `` and ``WXAgg `` backends require a
82
- framework build to function correctly. Unfortunately virtualenv creates a non
83
- framework build even if created from a framework build of Python. Conda
84
- environments are framework builds. From
85
- Matplotlib 1.5 onwards the ``macosx `` backend checks that a framework build is
86
- available and fails if a non framework build is found.
87
- WX has a similar check build in.
82
+ At the time of writing the ``macosx `` and ``WXAgg `` backends require a
83
+ framework build to function correctly. This can result in issues for
84
+ a python installation not build as a framework. In virtual envs and when
85
+ using (Ana)Conda. From Matplotlib 1.5 onwards the ``macosx `` backend
86
+ checks that a framework build is available and fails if a non framework
87
+ build is found. WX has a similar check build in.
88
+
89
+ Without this check a partially functional figure is created.
90
+ Among the issues with it is that it is produced in the background and
91
+ cannot be put in front of any other window.
92
+
93
+
94
+ OSX Conda
95
+ =========
96
+
97
+ The default python provided in (Ana)Conda is not a framework
98
+ build. However, the Conda developers have made it easy to install
99
+ a framework build in both the main environment and in Conda envs.
100
+ To use this install python.app ``conda install python.app `` and
101
+ use ``pythonw `` rather than ``python ``
102
+
103
+
104
+ OSX virtualenv
105
+ ==============
106
+
107
+ Unfortunately virtualenv creates a non
108
+ framework build even if created from a framework build of Python.
88
109
89
110
The issue has been reported on the virtualenv bug tracker `here
90
111
<https://github.com/pypa/virtualenv/issues/54> `__ and `here
91
112
<https://github.com/pypa/virtualenv/issues/609> `__
92
113
93
114
Until this is fixed, one of the following workarounds must be used:
94
115
116
+ ``PYTHONHOME `` Function
117
+ -----------------------
118
+
119
+ The best known work around is to use the non
120
+ virtualenv python along with the PYTHONHOME environment variable.
121
+ This can be done by defining a function in your ``.bashrc `` using
122
+
123
+ .. code :: bash
124
+
125
+ function frameworkpython {
126
+ if [[ ! -z " $VIRTUAL_ENV " ]]; then
127
+ PYTHONHOME=$VIRTUAL_ENV /usr/local/bin/python " $@ "
128
+ else
129
+ /usr/local/bin/python " $@ "
130
+ fi
131
+ }
132
+
133
+ This function can then be used in all of your virtualenvs without having to
134
+ fix every single one of them.
135
+
136
+ With this in place you can run ``frameworkpython `` to get an interactive
137
+ framework build within the virtualenv. To run a script you can do
138
+ ``frameworkpython test.py `` where ``test.py `` is a script that requires a
139
+ framework build. To run an interactive ``IPython `` session with the framework
140
+ build within the virtual environment you can do ``frameworkpython -m IPython ``
141
+
95
142
``PYTHONHOME `` Script
96
143
^^^^^^^^^^^^^^^^^^^^^
97
144
98
- The best known workaround,
99
- borrowed from the `WX wiki
100
- <http://wiki.wxpython.org/wxPythonVirtualenvOnMac> `_, is to use the non
145
+ An alternative work around borrowed from the `WX wiki
146
+ <http://wiki.wxpython.org/wxPythonVirtualenvOnMac> `_, is to use the non
101
147
virtualenv python along with the PYTHONHOME environment variable. This can be
102
148
implemented in a script as below. To use this modify ``PYVER `` and
103
149
``PATHTOPYTHON `` and put the script in the virtualenv bin directory i.e.
@@ -119,30 +165,8 @@ implemented in a script as below. To use this modify ``PYVER`` and
119
165
export PYTHONHOME=$ENV
120
166
exec $PYTHON " $@ "
121
167
122
-
123
- With this in place you can run ``frameworkpython `` to get an interactive
124
- framework build within the virtualenv. To run a script you can do
125
- ``frameworkpython test.py `` where ``test.py `` is a script that requires a
126
- framework build. To run an interactive ``IPython `` session with the framework
127
- build within the virtual environment you can do ``frameworkpython -m IPython ``
128
-
129
- ``PYTHONHOME `` Function
130
- ^^^^^^^^^^^^^^^^^^^^^^^
131
-
132
- Alternatively you can define a function in your ``.bashrc `` using
133
-
134
- .. code :: bash
135
-
136
- function frameworkpython {
137
- if [[ ! -z " $VIRTUAL_ENV " ]]; then
138
- PYTHONHOME=$VIRTUAL_ENV /usr/local/bin/python " $@ "
139
- else
140
- /usr/local/bin/python " $@ "
141
- fi
142
- }
143
-
144
- This function can then be used in all of your virtualenvs without having to
145
- fix every single one of them.
168
+ With this in place you can run ``frameworkpython `` as above but will need to add this script
169
+ to every virtualenv
146
170
147
171
PythonW Compiler
148
172
^^^^^^^^^^^^^^^^
0 commit comments