Pouvez-vous vérifier que os.environ['DISPLAY'] est le même dans IPython que dans le shell Python vanille ?

Je suppose que c'est peut-être matplotlib qui choisit un backend différent, bien que je ne sache pas pourquoi il le ferait.

À droite-- J'ai oublié de mentionner que je l'exécute sur un nœud principal de cluster qui n'a pas d'affichage. Il n'y a donc pas de $DISPLAY ( os.environ['DISPLAY'] donne un KeyError sur les deux shells).

Et si je définis explicitement le backend sur 'agg' je n'obtiens pas non plus l'erreur, mais j'aimerais éviter d'avoir à le faire chaque fois que je lance ipython et que je veux importer quelque chose qui importe matplotlib.

Utilisez-vous l'interface de terminal IPython ou IPython en tant que noyau dans une interface Jupyter ? Je pense qu'IPython en tant que noyau définit la variable d'environnement MPLBACKEND pour produire des tracés en ligne par défaut, mais cela ne devrait pas se produire avec IPython dans le terminal. Et je ne pense pas que les tracés en ligne aient besoin d'un serveur X, de toute façon. :-/

J'utilisais juste l'interface du terminal ipython. Il semblerait que si un DISPLAY n'est pas disponible, le backend devrait utiliser par défaut quelque chose qui n'en a pas besoin, mais cela ne semble pas se produire.

@tacaswell avez-vous une idée de la raison pour laquelle IPython pourrait affecter le backend par défaut ici ?

Cela se produit parce que le backend par défaut pour Matplotlib dans Anaconda est Qt5. Nous envisageons de le changer en Tk pour éviter ce genre de problèmes.

Passer à Tk aurait toujours le même problème.

Je pense qu'il apparaît immédiatement avec IPython vs python car si pyplot est importé à l'intérieur d'IPython, il remarque et configure l'intégration de la boucle d'événement. Dans l'invite simple, vous obtiendrez éventuellement un problème lorsque l'utilisateur essaiera de créer un tracé.

Je pense que passer à tk par défaut serait moins que génial.

Je pense que passer à tk par défaut serait moins que génial.

Que voulez-vous dire exactement? Pensez-vous qu'il est préférable pour Anaconda de rester avec Qt5 ?

Qt5 est un framework plus agréable et prend en charge les écrans haute résolution prêts à l'emploi, je pense que revenir à Tk serait une régression de l'expérience utilisateur.

D'accord, nous sommes juste un peu inquiets à propos du notebook fonctionnant dans des conteneurs Docker sans tête. Mais avec Matplotlib 1.5 (je pense), le notebook sélectionne automatiquement inline comme son backend par défaut, non ?

C'est entièrement du côté de jupyter.

Si la variable d'environnement MPLBACKEND n'est pas déjà définie, ipykernel la définit pour qu'elle fasse référence au backend en ligne. Les commentaires dans notre code source indiquent que cela affectera mpl >= 1.5, et qu'il est prioritaire sur matplotlibrc mais pas sur le choix explicite d'un backend dans le code.

C'est vraiment cool! Alors je dirais que cela peut être fermé.

L'OP peut simplement définir 'agg' comme backend par défaut de Matplotlib dans son matplotlibrc pour éviter cette erreur.

En relisant ceci, je remarque qu'il s'agissait à l'origine du terminal IPython, pas du noyau. Ce que j'ai dit ci-dessus à propos de la configuration de MPLBACKEND ne s'applique pas au terminal IPython.

Je vais fermer ceci maintenant car je ne pense pas que ce qui est signalé soit un bogue dans IPython. C'est peut-être à l'utilisateur de configurer un backend sans tête, ou peut-être que la vérification "à l'intérieur d'IPython" de MPL devrait également vérifier s'il se trouve dans un environnement sans tête. Quoi qu'il en soit, je ne pense pas qu'IPython puisse faire quoi que ce soit pour le réparer.

N'hésitez pas à continuer à utiliser cette question comme un endroit pour en discuter, cependant.

Oui, il semble clair que ce n'est pas un bogue ipython. Je pense que MPL devrait faire les vérifications pour permettre à quelqu'un de lancer un shell ipython et d'importer matplotlib.pyplot, et que cela ne plante pas, sans avoir à modifier les options de matplotlibrc ou à définir explicitement le backend.

@timothydmorton Le problème fait la différence entre "L'utilisateur vient de demander d'utiliser un backend GUI, mais ils le voulaient en quelque sorte et nous devrions nous rabattre sur Agg" vs "L'utilisateur vient de demander d'utiliser un backend GUI, nous ne pouvons pas car il n'y a pas de serveur X en cours d'exécution, nous devons donc le leur faire savoir" à partir d'une entrée de chaîne. Le compromis a historiquement été en faveur des utilisateurs interactifs et a empêché le bogue « pas de tracé affiché » et laissé le bogue « Je ne peux pas utiliser un backend interactif sur un serveur sans tête » se produire car dans ce dernier cas, l'utilisateur obtient un clair erreur sur ce qui ne va pas.

Il y a eu des discussions récemment sur la façon de prendre en charge "quelle que soit la saveur Qt installée" en tant que backend et comment faire des backends backend, mais cela devient difficile en général car les frameworks GUI ont tendance à se marcher sur les pieds si vous les importez simultanément.

Je suis également affecté par ce problème, et je ne peux pas penser à un bon travail en plus d'utiliser python ordinaire au lieu d'ipython.

@russelljjarvis c'est un désagrément mineur, mais si la première commande que vous exécutez lorsque vous démarrez ipython est import matplotlib; matplotlib.use('agg') alors ipython devrait fonctionner pour vous.

Oui:

import matplotlib; matplotlib.use('agg')

C'est la première commande que j'exécute, mais j'obtiens toujours :

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

Une fois que le programme a rencontré une erreur, il me reste généralement une invite de débogage et un patch de singe.

J'invoque python avec ipython -i file_name.py après la première exécution : ipcluster start -n 8 --profile=default &

Où la première ligne de file_name est import matplotlib; matplotlib.use('agg')

Je me demande si l'exécution d'ipcluster pourrait être à l'origine des problèmes.

Il existe une solution utilisant des variables d'environnement disponibles ici :

Le réglage de export QT_QPA_PLATFORM='offscreen' dans mon .bash_profile fonctionné pour moi.

Un collègue a récemment suggéré la même chose. Dans le contexte de Docker, votre déclaration serait :
ENV QT_QPA_PLATFORM offscreen . Je le teste effectivement maintenant.

Je reçois la même erreur:

Le paramètre export QT_QPA_PLATFORM='offscreen' changé le message d'erreur en :

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

solution dans le cahier directement

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

En guise de suivi tardif, à partir de Matplotlib 3.0, nous prenons désormais en charge la sélection automatique du backend et n'essaierons pas d'utiliser un backend GUI sur un serveur sans tête (mais respecterons toujours un fichier rcparams qui nous le demande).

Cette réponse https://unix.stackexchange.com/questions/192642/wkhtmltopdf-qxcbconnection-could-not-connect-to-display
Résolu après l'installation manuelle

"conda update matplotlib" a résolu le problème pour moi.

Le réglage suivant fonctionne !!!

export QT_QPA_PLATFORM='hors écran'

En tant que suivi tardif, à partir de Matplotlib 3.0, nous prenons désormais en charge la sélection automatique du backend et n'essaierons pas d'utiliser un backend GUI sur un serveur sans tête (mais respecterons toujours un fichier rcparams qui nous le demande)

Matplotlib 3.1 ne peut pas prendre en charge le backend automatique, nous devons définir manuellement 'Agg' .

Cela se produit parce que le backend par défaut pour Matplotlib dans Anaconda est Qt5. Nous envisageons de le changer en Tk pour éviter ce genre de problèmes.

où puis-je changer celui-ci ?

Ceci est mon erreur après avoir défini 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.

Après avoir défini QT_QPA_PLATFORM='offscreen' les importations des bibliothèques matplotlib et fastai s'exécutent.
Cependant, plt.figure() ou toute autre commande produisant un tracé génère les erreurs suivantes :

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

j'ai aussi cette erreur