Get best of the week

Depurador Visual para Jupyter

O progresso da maioria dos projetos de software é baseado em pequenas alterações, que, antes de prosseguir, são cuidadosamente avaliadas. Resultados rápidos de execução de código e alta velocidade de desenvolvimento iterativo são algumas das principais razões para o sucesso do Jupyter. Especialmente no campo da pesquisa científica.

Os usuários do Jupyter adoram experimentar notebooks; eles usam os notebooks como um meio interativo de comunicação. No entanto, se falarmos sobre as tarefas do desenvolvimento clássico de software, por exemplo, refatorar uma grande base de código, podemos dizer que, para resolver esses problemas, o Jupyter é frequentemente substituído por IDEs regulares.


O ambiente JupyterLab O

projeto Jupyter trabalha há vários anos para fechar a lacuna entre notebooks e IDEs regulares. Esses esforços são amplamente representados pela plataforma JupyterLab, que fornece ao desenvolvedor uma interface mais avançada e conveniente, que inclui um gerenciador de arquivos, editores de texto, consoles e blocos de notas.

É verdade que, até recentemente, algo estava faltando no JupyterLab. Essa é a principal razão pela qual os usuários foram forçados a mudar para outros ambientes. Os usuários do Jupyter não tinham um depurador visual. Usuários, especialmente aqueles que estão acostumados a IDEs regulares, há muito tempo solicitam esse recurso.

Depurador para Jupyter


Hoje, após vários meses de desenvolvimento, temos o prazer de apresentar o primeiro lançamento público do depurador visual para Jupyter!

Esta é apenas a primeira versão, mas o depurador já permite definir pontos de interrupção nas células do notebook e nos arquivos de origem. Permite examinar o conteúdo das variáveis, visualizar a pilha de chamadas. E suas capacidades não se limitam a isso.


Depurador Visual Jupyter em ação

Testando o depurador no site do projeto do fichário



O projeto do fichário Você pode

tentar um novo depurador no caso no site do projeto do fichário. Aqui está um bloco de notas demo com o qual você pode experimentar.

Instalação


O frontend do depurador pode ser instalado como uma extensão JupyterLab:

jupyter labextension install @jupyterlab/debugger

Em versões futuras, o front-end do depurador será incluído no JupyterLab por padrão.

No back-end, para que o depurador funcione, deve haver um kernel no qual o Protocolo de Depuração Jupyter é implementado (falaremos mais sobre isso abaixo). Até agora, o único kernel que implementa esse protocolo é o xeus-python . É o núcleo do Jupyter para a linguagem de programação Python. (Os planos de desenvolvimento do projeto também incluem suporte ao protocolo debugger no ipykernel.)

Você pode instalar o kernel xeus-python assim:

conda install xeus-python -c conda-forge

Após a instalação do xeus-python e da extensão do depurador, tudo estará pronto para funcionar com o depurador visual do Jupyter.

Preste atenção ao fato de que também existem "rodas" de PyPI para o xeus-python, mas elas ainda têm status experimental e sua disponibilidade depende da plataforma.

Detalhes do Protocolo de Depuração Jupyter


Novos tipos de mensagens para os canais Control e IOPub


Os kernels Jupyter (a parte da infraestrutura que executa o código do usuário) se comunicam com outras partes do sistema usando um protocolo de comunicação entre processos bem desenvolvido .

Existem vários canais de comunicação:

  • Um canal Shellque funciona de acordo com o esquema de solicitação / resposta e é usado, por exemplo, para solicitações de execução de código.
  • Um canal IOPub, que é um canal de comunicação unidirecional que é executado do núcleo para o cliente. É usado, por exemplo, para redirecionar fluxos de saída padrão ( stdoute stderr).
  • Um canal Controlsemelhante a um canal, Shellmas operando em um soquete diferente. Por esse motivo, suas mensagens não são enfileiradas juntamente com solicitações de execução de código e têm uma prioridade mais alta. O canal Controljá foi usado para consultas Interrupte Shutdown. Decidimos usá-lo para comandos enviados ao depurador.

Dois novos tipos de mensagens foram adicionados ao protocolo:


▍ Debug Adapter Protocol


O princípio chave da arquitetura Jupyter é a falta de ligação a uma determinada linguagem de programação. Portanto, é importante que o protocolo depurador suporte a adaptação a várias implementações do kernel.

Um padrão de depuração popular é o DAP (Debug Adapter Protocol), desenvolvido pela Microsoft. Este é um protocolo baseado em JSON que, por exemplo, é subjacente ao subsistema de depuração do Visual Studio Code. Este protocolo suporta muitos back-end projetados para diferentes idiomas.

Como resultado, foi completamente natural que usássemos mensagens DAP por meio de mensagens adicionadas recentemente debug_[request/reply]e debug_event.

No entanto, no caso de Jupyter, isso não foi suficiente:

  • , , , Jupyter ( , , ). debug_request.
  • , , Jupyter, , , , , , .

O conteúdo das solicitações ao depurador e suas respostas, além dessas duas diferenças, corresponde ao DAP.

Todas essas extensões ao protocolo do kernel Jupyter foram propostas como candidatas à inclusão na especificação oficial. Uma proposta de desenvolvimento relacionada ao Jupyter (JEPyter Enhancement Proposal, JEP) pode ser encontrada aqui .

Xeus-python é o primeiro kernel Jupyter a suportar depuração


Xeus é uma implementação em C ++ do protocolo do kernel Jupyter. Este, por si só, não é o núcleo. Esta é uma biblioteca que ajuda a desenvolver kernels. Essa biblioteca é útil no desenvolvimento de kernels para linguagens que possuem uma API C ou C ++ (como Python, Lua ou SQL). Ela cuida das tarefas demoradas de implementar o protocolo de mensagens Jupyter. Isso permite que o autor do kernel se concentre em tarefas relacionadas à interpretação de construções de linguagem: na execução de código, em sua análise e assim por diante.

Vários kernels foram desenvolvidos usando o xeus, incluindo o popular núcleo xeus-cling para C ++, com base no intérprete de cling C ++ criado no CERN. O kernel xeus-python é uma alternativa do ipykernel baseada no xeus. Aquimaterial sobre o primeiro lançamento do kernel xeus-python.

O kernel xeus-python é adequado para a primeira implementação do protocolo debugger por vários motivos:

  • Ele suporta a execução competitiva de código, que permite executar o trabalho com o canal Controlem um thread separado.
  • Possui uma base de código compacta. Graças a isso, este kernel é uma boa "caixa de areia", na qual é conveniente implementar algo novo. A implementação da primeira versão do protocolo depurador no ipykernel exigiria uma refatoração mais séria e mais esforço para coordenar as mudanças nos estágios iniciais do desenvolvimento.

Plan Plano de desenvolvimento do kernel Xeus-python


Entre os objetivos de desenvolvimento de curto prazo do xeus-python estão os seguintes:

  • Adicionando suporte para recursos IPython. Agora isso, comparado ao ipykernel, é o principal recurso que falta no xeus-python.
  • Melhoria das "rodas" de PyPI do xeus-python.

▍Sobre outros núcleos


O que já foi feito em termos de suporte à depuração no frontend pode ser usado com qualquer kernel que implementa o protocolo estendido do kernel.

Este ano, trabalharemos para fornecer suporte à depuração no maior número possível de núcleos.

Em breve, haverá suporte para depuração para outros kernels baseados em xeus que têm muito em comum com o kernel xeus-python. Por exemplo, para xeus-cling.

Detalhes da arquitetura do front-end do depurador


A extensão do depurador para JupyterLab fornece aos usuários os mecanismos geralmente esperados do IDE:

  • Barra lateral com janelas que implementam os seguintes recursos: monitoramento de variáveis, visualização de pontos de interrupção, visualização de código, análise de pilhas de chamadas.
  • A capacidade de definir pontos de interrupção diretamente no código, em particular no código localizado nas células do bloco de notas e nos consoles.
  • Marcadores visuais indicando a posição em que a execução do código parou.

Ao trabalhar com blocos de anotações Jupyter, informações sobre o status da execução do código são armazenadas no kernel. Mas o código da célula pode ser executado, após o qual essa célula pode ser excluída do notebook. O que deve acontecer se o usuário, durante a depuração, quiser inserir um bloco de código remoto?

A extensão suporta esse cenário específico e pode exibir o código de uma célula executada anteriormente no modo somente leitura.


Mudando para o código localizado na célula remota Você

pode depurar o código localizado nos consoles e nos arquivos.


Depurando código do console no JupyterLab


Depuração no JupyterLab, o código no arquivo A

depuração pode ser ativada no nível do bloco de notas, o que permitirá aos usuários depurar o bloco de notas e, ao mesmo tempo, trabalhar com outro bloco de notas.


Depurando vários notebooks ao mesmo tempo As

variáveis ​​podem ser visualizadas usando uma exibição em árvore ou tabela.


Ferramentas para

explorar variáveis A extensão do depurador para JupyterLab foi projetada para funcionar com qualquer kernel que suporta depuração.

Devido ao fato de a extensão depender do protocolo DAP, ela abstrai os recursos de vários idiomas e fornece ao usuário uma interface de depuração consistente.

O diagrama a seguir mostra o fluxo de mensagens enviadas durante uma sessão de depuração entre o usuário, a extensão JupyterLab e o kernel.


Usando o Debug Adapter Protocol em um depurador ( origem )

Planos futuros


Em 2020, planejamos melhorar seriamente o depurador. Ou seja, estamos falando sobre o seguinte:

  • Suporte para saída de vários tipos MIME na janela do explorador de variáveis.
  • Suporte para trabalhar com pontos de interrupção condicionais na interface do depurador.
  • Melhorando a usabilidade da interface do depurador.
  • Implementando a capacidade de depurar aplicativos Voilà da extensão @jupyter-voila/jupyterlab-preview.

Queridos leitores! Você já tentou o depurador visual Jupyter?

More articles:


All Articles