¿Puedes comprobar que os.environ['DISPLAY'] es lo mismo en IPython que en el shell de Python de vainilla?

Supongo que podría ser matplotlib eligiendo un backend diferente, aunque no estoy seguro de por qué lo haría.

Bien, olvidé mencionar que estoy ejecutando esto en un nodo principal del clúster que no tiene pantalla. Por lo tanto, no hay un conjunto de $ DISPLAY ( os.environ['DISPLAY'] da un KeyError en ambos shells).

Y si establezco explícitamente el backend en 'agg' , tampoco obtengo el error, pero me gustaría evitar tener que hacerlo cada vez que lanzo ipython y quiero importar algo que importe matplotlib.

¿Está utilizando la interfaz de terminal IPython o IPython como núcleo en una interfaz de Jupyter? Creo que IPython como kernel establece la variable de entorno MPLBACKEND para producir gráficos en línea de forma predeterminada, pero eso no debería suceder con IPython en la terminal. Y no creo que los gráficos en línea necesiten un servidor X, de todos modos. : - /

Solo estaba usando la interfaz de terminal ipython. Parecería que si un DISPLAY no está disponible, entonces el backend debería usar de forma predeterminada algo que no lo necesita, pero que no parece estar sucediendo.

@tacaswell ¿ alguna idea de por qué IPython podría estar afectando al backend predeterminado aquí?

Esto sucede porque el backend predeterminado para Matplotlib en Anaconda es Qt5. Estamos considerando cambiarlo a Tk para evitar este tipo de problemas.

Cambiar a Tk todavía tendría el mismo problema.

Creo que aparece de inmediato con IPython vs python porque si pyplot se importa dentro de IPython, se da cuenta y configura la integración del bucle de eventos. En el indicador simple, eventualmente obtendría un problema cuando el usuario intentara hacer un diagrama.

Creo que pasar a tk por defecto no sería genial.

Creo que pasar a tk por defecto no sería genial.

¿Qué quieres decir exactamente? ¿Crees que es mejor que Anaconda se quede con Qt5?

Qt5 es un marco más agradable y admite pantallas de alta resolución de fábrica, creo que volver a Tk sería una regresión en la experiencia del usuario.

De acuerdo, estamos un poco preocupados por la ejecución del portátil en contenedores Docker sin cabeza. Pero con Matplotlib 1.5 (creo), el portátil selecciona automáticamente inline como su backend predeterminado, ¿verdad?

Eso está completamente del lado de Jupyter.

Si la variable de entorno MPLBACKEND no está configurada, ipykernel la configura para hacer referencia al backend en línea. Los comentarios en nuestro código fuente dicen que esto afectará a mpl> = 1.5, y que tiene prioridad sobre matplotlibrc pero no sobre la selección explícita de un backend en el código.

¡Eso es realmente genial! Entonces diría que esto se puede cerrar.

El OP puede simplemente establecer 'agg' como el backend predeterminado de Matplotlib en su matplotlibrc para evitar este error.

Al releer esto, me doy cuenta de que originalmente se trataba de la terminal IPython, no del kernel. Lo que dije anteriormente sobre la configuración de MPLBACKEND no se aplica al terminal IPython.

Cerraré esto ahora porque no creo que lo que se informa sea un error en IPython. Tal vez dependa del usuario configurar un backend sin cabeza, o tal vez la verificación "dentro de IPython" de MPL también debería verificar si está en un entorno sin cabeza. De cualquier manera, no creo que haya nada que pueda hacer IPython para solucionarlo.

Sin embargo, siéntase libre de seguir usando este tema como un lugar para discutirlo.

Sí, parece claro que no es un error de ipython. Creo que MPL debería hacer las comprobaciones para permitir que alguien lance un shell ipython e importe matplotlib.pyplot, y que no se bloquee, sin tener que cambiar ninguna opción de matplotlibrc o establecer explícitamente el backend.

@timothydmorton El problema es diferenciar entre "El usuario acaba de pedir usar un backend GUI, pero solo lo

Recientemente hubo una discusión sobre cómo admitir "cualquier versión de Qt que esté instalada" como backend y cómo hacer backend de respaldo, pero en general se vuelve complicado porque los frameworks de GUI tienden a pisotear los dedos de los demás si los importas simultáneamente.

También me afecta este problema, y ​​no puedo pensar en un buen trabajo además de usar Python normal en lugar de ipython.

@russelljjarvis es una molestia menor, pero si el primer comando que ejecuta cuando inicia ipython es import matplotlib; matplotlib.use('agg') entonces ipython debería funcionar para usted.

Sí:

import matplotlib; matplotlib.use('agg')

Es el primer comando que ejecuto, pero todavía obtengo:

In [1]: QXcbConnection: Could not connect to display :0
Aborted

Después de que el programa haya encontrado un error, y por lo general me quedaría con un mensaje para depurar y parchear.

Invoco python con ipython -i file_name.py después de la primera ejecución: ipcluster start -n 8 --profile=default &

Donde la primera línea de file_name es import matplotlib; matplotlib.use('agg')

Me pregunto si ejecutar ipcluster podría estar causando los problemas.

Hay una solución que utiliza variables de entorno disponibles aquí :

Establecer export QT_QPA_PLATFORM='offscreen' en mi .bash_profile funcionó para mí.

Un colega sugirió recientemente lo mismo. En el contexto de Docker, su declaración sería:
ENV QT_QPA_PLATFORM offscreen . Lo estoy probando efectivamente ahora.

Estoy teniendo el mismo error:

La configuración de export QT_QPA_PLATFORM='offscreen' cambió el mensaje de error a:

(python:17399): Gtk-WARNING **: cannot open display:

solución en el cuaderno directamente

import os
os.environ['QT_QPA_PLATFORM']='offscreen'

Como seguimiento tardío, a partir de Matplotlib 3.0 ahora admitimos la selección automática de backend y no intentaremos usar un backend GUI en un servidor sin cabeza (pero aún respetaremos un archivo rcparams que nos lo solicite).

Esta respuesta https://unix.stackexchange.com/questions/192642/wkhtmltopdf-qxcbconnection-could-not-connect-to-display
Resuelto después de instalarlo manualmente

"Conda update matplotlib" solucionó el problema por mí.

¡La siguiente configuración funciona!

exportar QT_QPA_PLATFORM = 'fuera de pantalla'

Como seguimiento tardío, a partir de Matplotlib 3.0 ahora admitimos la selección automática de backend y no intentaremos usar un backend GUI en un servidor sin cabeza (pero aún respetaremos un archivo rcparams que nos lo solicite)

Matplotlib 3.1 no puede soportar backend automático, necesitamos configurar manualmente 'Agg'.

Esto sucede porque el backend predeterminado para Matplotlib en Anaconda es Qt5. Estamos considerando cambiarlo a Tk para evitar este tipo de problemas.

¿Dónde puedo cambiar este?

Este es mi error después de configurar export QT_QPA_PLATFORM=offscreen

[tb571<strong i="7">@da02</strong> ~]$ jupyter console --kernel slicer-4.11
qt.qpa.plugin: Could not find the Qt platform plugin "offscreen" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Después de configurar QT_QPA_PLATFORM='offscreen' ejecutan las importaciones de las bibliotecas matplotlib y fastai.
Sin embargo, plt.figure () o cualquier otro comando que genere un gráfico genera los siguientes errores:

This plugin does not support propagateSizeHints()
This plugin does not support raise()

También recibo este error