Você pode verificar se os.environ['DISPLAY'] é o mesmo no IPython e no shell Python vanilla?

Eu acho que pode ser matplotlib escolhendo um back-end diferente, embora eu não saiba por que faria isso.

Certo - esqueci de mencionar que estou executando isso em um nó principal do cluster que não tem uma tela. Portanto, não há $ DISPLAY definido ( os.environ['DISPLAY'] dá um KeyError em ambos os shells).

E se eu definir explicitamente o back-end como 'agg' , também não recebo o erro, mas gostaria de evitar ter que fazer isso toda vez que iniciar o ipython e quiser importar algo que importe matplotlib.

Você está usando a interface de terminal IPython ou IPython como um kernel em uma interface Jupyter? Eu acho que IPython como um kernel define a variável de ambiente MPLBACKEND para produzir plotagens embutidas por padrão, mas isso não deveria acontecer com IPython no terminal. E eu não acho que os gráficos embutidos precisam de um servidor X, de qualquer maneira. : - /

Eu estava usando a interface do terminal ipython. Parece que, se DISPLAY não estiver disponível, o back-end deve usar como padrão algo que não precisa dele, mas isso não parece estar acontecendo.

@tacaswell alguma idéia de por que o IPython pode estar afetando o back-end padrão aqui?

Isso acontece porque o backend padrão para Matplotlib no Anaconda é Qt5. Estamos considerando alterá-lo para Tk para evitar esse tipo de problema.

Mudar para Tk ainda teria o mesmo problema.

Acho que está aparecendo imediatamente com IPython vs python porque se pyplot for importado dentro do IPython, ele percebe e configura a integração do loop de eventos. No prompt simples, você teria um problema, eventualmente, quando o usuário tentasse fazer um gráfico.

Acho que mudar para tk como padrão seria menos do que ótimo.

Acho que mudar para tk como padrão seria menos do que ótimo.

O que você quer dizer exatamente? Você acha que é melhor para o Anaconda ficar com o Qt5?

Qt5 é um framework melhor e suporta telas de alta resolução prontas para o uso, acho que voltar ao Tk seria uma regressão na experiência do usuário.

Ok, estamos um pouco preocupados com o notebook rodando em contêineres Docker sem cabeça. Mas com Matplotlib 1.5 (eu acho), o notebook seleciona automaticamente inline como seu back-end padrão, certo?

Isso está inteiramente no lado jupyter.

Se a variável de ambiente MPLBACKEND ainda não estiver definida, o ipykernel a define para se referir ao backend embutido. Os comentários em nosso código-fonte dizem que isso afetará mpl> = 1.5 e que tem prioridade sobre matplotlibrc, mas não sobre a escolha explícita de um back-end no código.

Isso é muito legal! Então eu diria que isso pode ser fechado.

O OP pode simplesmente definir 'agg' como backend padrão do Matplotlib em seu matplotlibrc para evitar esse erro.

Relendo isto, noto que era originalmente sobre IPython de terminal, não o kernel. O que eu disse acima sobre a configuração de MPLBACKEND não se aplica ao terminal IPython.

Vou encerrar agora porque não acho que o que foi relatado seja um bug no IPython. Talvez seja responsabilidade do usuário configurar um back-end sem cabeçalho, ou talvez a verificação "dentro do IPython" do MPL também deva verificar se está em um ambiente sem cabeçalho. De qualquer forma, não acho que haja nada que o IPython possa fazer para corrigir isso.

No entanto, sinta-se à vontade para continuar usando esse assunto como um lugar para discuti-lo.

Sim, parece claro que não é um bug do ipython. Eu acho que o MPL deve fazer as verificações para permitir que alguém inicie um shell ipython e importe matplotlib.pyplot, e isso não travar, sem ter que alterar nenhuma opção de matplotlibrc ou definir explicitamente o back-end.

@timothydmorton O problema é dizer a diferença entre "O usuário acabou de pedir para usar um back-end da GUI, mas eles apenas quiseram dizer isso e devemos voltar para Agg" vs "O usuário acabou de pedir para usar um back-end da GUI, não podemos porque não há um servidor X em execução, devemos informá-los "a partir de uma entrada de string. A troca tem sido historicamente a favor dos usuários interativos, evitando o bug "nenhum gráfico apareceu" e permitindo que o bug "Não posso usar um back-end interativo em um servidor sem comando" aconteça porque, no último caso, o usuário obtém uma resposta clara erro quanto ao que está errado.

Houve alguma discussão recentemente sobre como suportar "qualquer tipo de Qt instalado" como um backend e como fazer fallbacks de backend, mas fica complicado em geral porque os frameworks GUI tendem a pisar nos calcanhares uns dos outros se você importá-los simultaneamente.

Também sou afetado por esse problema e não consigo pensar em uma boa alternativa além de usar python regular em vez de ipython.

@russelljjarvis é um aborrecimento menor, mas se o primeiro comando que você executar ao iniciar o ipython for import matplotlib; matplotlib.use('agg') então o ipython deve funcionar para você.

Sim:

import matplotlib; matplotlib.use('agg')

É o primeiro comando que executo, mas ainda consigo:

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

Depois que o programa atinge um erro, e geralmente eu fico com um prompt para depurar e corrigir o macaco.

Eu invoco python com ipython -i file_name.py após a primeira execução: ipcluster start -n 8 --profile=default &

Onde a primeira linha de file_name é import matplotlib; matplotlib.use('agg')

Eu me pergunto se a execução do ipcluster pode estar causando os problemas.

Há uma solução usando variáveis ​​de ambiente disponíveis aqui :

Definir export QT_QPA_PLATFORM='offscreen' no meu .bash_profile funcionou para mim.

Um colega sugeriu recentemente a mesma coisa. No contexto do Docker, sua declaração seria:
ENV QT_QPA_PLATFORM offscreen . Estou efetivamente testando isso agora.

Estou recebendo o mesmo erro:

A configuração export QT_QPA_PLATFORM='offscreen' alterou a mensagem de erro para:

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

solução no notebook diretamente

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

Como um acompanhamento tardio, a partir do Matplotlib 3.0, agora suportamos a seleção automática de backend e não tentaremos usar um backend GUI em um servidor headless (mas ainda respeitará um arquivo rcparams que nos solicite).

Esta resposta https://unix.stackexchange.com/questions/192642/wkhtmltopdf-qxcbconnection-could-not-connect-to-display
Resolvido após a instalação manualmente

"conda update matplotlib" corrigiu o problema para mim.

A configuração a seguir funciona !!!

exportar QT_QPA_PLATFORM = 'fora da tela'

Como um acompanhamento tardio, a partir do Matplotlib 3.0, agora suportamos a seleção automática de back-end e não tentaremos usar um back-end GUI em um servidor headless (mas ainda respeitará um arquivo rcparams que nos pede)

Matplotlib 3.1 não suporta backend automático, precisamos definir manualmente o 'Agg'.

Isso acontece porque o backend padrão para Matplotlib no Anaconda é Qt5. Estamos considerando alterá-lo para Tk para evitar esse tipo de problema.

onde posso mudar este?

Este é o meu erro após definir 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.

Depois de definir QT_QPA_PLATFORM='offscreen' as importações das bibliotecas matplotlib e fastai são executadas.
No entanto, plt.figure () ou qualquer outro comando gerando um gráfico gera os seguintes erros:

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

Estou recebendo este erro também