@@ -27,9 +27,7 @@ Detailed description
27
27
The problem
28
28
~~~~~~~~~~~
29
29
30
- Current ("old-style") configuration files use a custom syntax, of the form
31
-
32
- .. code :: conf
30
+ Current ("old-style") configuration files use a custom syntax, of the form ::
33
31
34
32
key: value # possible comment
35
33
key: value
@@ -115,9 +113,7 @@ which file-parser to use.
115
113
Maintain a matplotlibrc-like syntax
116
114
```````````````````````````````````
117
115
118
- The config files would maintain the format
119
-
120
- .. code :: conf
116
+ The config files would maintain the format ::
121
117
122
118
key: value # possible comment
123
119
key: value
@@ -205,6 +201,34 @@ convention is changed (e.g. ``.mplstyle-v2`` with the matplotlibrc-like syntax,
205
201
or ``.py ``\( !) with the full Python syntax), then a simple priority policy
206
202
(such as "always prefer the newer syntax if available") can be implemented.
207
203
204
+ Runtime detection for the default backend
205
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
206
+
207
+ As an additional benefit, either approach would allow setting the backend to
208
+ the first of a list of supported backends *at import time *. Specifically,
209
+ ``setup.py `` currently checks *at build time * what is the "best" "available"
210
+ backend, where "best" is defined by a fixed ordering (OSX > Qt5Agg > ...) and
211
+ "available" means that the platform is supported (macosx is only supported on
212
+ OSX) and the dependencies are installed (PyQt5 for Qt5Agg, etc.). The result
213
+ of this check is written to the default ``matplotlibrc ``, and used as the
214
+ default backend. Not only this code is fairly complex (in particular because
215
+ one can generally not import multiple GUI toolkits in a single process -- in
216
+ truth this could be fixed by just checking whether the module is available,
217
+ *without * importing it), but more importantly, this default backend can
218
+ easily be incorrect if the build environment is not the same as the install
219
+ environment (quite common with wheels, conda packages and Linux packages),
220
+ or become incorrect if the end-user installs or uninstalls some GUI toolkits
221
+ (`#3679 `_, `#8613 `_). The desired default backend may even depend on whether
222
+ the environement is headless (`#6739 `_).
223
+
224
+ With an interpreted ``matplotlibrc ``, this problem disappears: we can simply
225
+ provide a ``first_available_backend `` function that finds *at runtime * the
226
+ first available backend from a list, and write something like ::
227
+
228
+ rcParams["backend"] = first_available_backend(["macosx", "qt5agg", ...])
229
+
230
+ to the default ``matplotlibrc ``.
231
+
208
232
Implementation
209
233
--------------
210
234
@@ -241,16 +265,39 @@ Alternatives
241
265
discussion that took place over PEP518 _ (not that I particularly like the
242
266
final choice of yet another obscure configuration language by that PEP).
243
267
268
+ Relevant issues
269
+ ---------------
270
+
271
+ - `#3670 `_: "Document that rcparam values are unquoted"
272
+ - `#3679 `_: "Runtime detection for default backend"
273
+ - `#4240 `_: "Style RC parameter"
274
+ - `#4371 `_: "LaTeX and PGF preambles do not allow commas"
275
+ - `#6157 `_: "Add style for xkcd"
276
+ - `#6274 `_: "A feeble attempt to plug a theoretical security hole"
277
+ - `#6320 `_: "all matplotlibrc files should be loaded in order"
278
+ - `#6739 `_: "Make matplotlib fail more gracefully in headless environments"
279
+ - `#7089 `_: "matplotlibrc reader cannot handle rcparams with a hash"
280
+ - `#7219 `_: "Cycler passed as string for rc"
281
+ - `#8235 `_: "Investigate why some examples build properly in our gallery
282
+ despite using numpy and not importing it explicitely"
283
+ - `#8430 `_: "[feature request] move default colors into styles"
284
+ - `#8613 `_: "matplotlibrc: is there a way to specify "backend" as either
285
+ "Qt5Agg | Qt4Agg" (whatever is installed)?"
286
+ - `#9184 `_: "matplotlibrc parsing is inconsistent with matplotlibrc.template"
287
+
244
288
.. _#3670 : https://github.com/matplotlib/matplotlib/issues/3670
289
+ .. _#3679 : https://github.com/matplotlib/matplotlib/issues/3679
245
290
.. _#4240 : https://github.com/matplotlib/matplotlib/issues/4240
246
291
.. _#4371 : https://github.com/matplotlib/matplotlib/issues/4371
247
292
.. _#6157 : https://github.com/matplotlib/matplotlib/issues/6157
248
293
.. _#6274 : https://github.com/matplotlib/matplotlib/issues/6274
249
294
.. _#6320 : https://github.com/matplotlib/matplotlib/issues/6320
295
+ .. _#6739 : https://github.com/matplotlib/matplotlib/issues/6739
250
296
.. _#7089 : https://github.com/matplotlib/matplotlib/issues/7089
251
297
.. _#7219 : https://github.com/matplotlib/matplotlib/issues/7219
252
- .. _#8235 : https://github.com/matplotlib/matplotlib/issues/8430
298
+ .. _#8235 : https://github.com/matplotlib/matplotlib/issues/8235
253
299
.. _#8430 : https://github.com/matplotlib/matplotlib/issues/8430
300
+ .. _#8613 : https://github.com/matplotlib/matplotlib/issues/8613
254
301
.. _#9184 : https://github.com/matplotlib/matplotlib/issues/9184
255
302
.. _PEP518 : https://www.python.org/dev/peps/pep-0518/#other-file-formats
256
303
.. _explicit-imports : https://www.reddit.com/r/Python/comments/ex54j/seeking_clarification_on_pylonsturbogearspyramid/c1bo1v5/
0 commit comments