zulip terminal
Zulip Terminal 0.7.0
Mudanças recentes | Configuração | Teclas quentes | Perguntas frequentes | Desenvolvimento | Tutorial
O Zulip Terminal é o cliente oficial do Terminal para Zulip, fornecendo uma interface de usuário baseada em texto (TUI).
Objetivos específicos incluem:
Aprenda a usar o terminal Zulip com nosso tutorial.
Consideramos que o cliente já fornece uma experiência de usuário cotidiano bastante estável com recursos moderados.
O foco atual do desenvolvimento é melhorar os aspectos do uso diário que são mais comumente usados - para reduzir a necessidade de os usuários mudarem temporariamente para outro cliente para um recurso específico.
As limitações atuais que esperamos resolver apenas a longo prazo incluem suporte para:
Atualmente, o cliente terminal possui várias diferenças intencionais para o Zulip Web Client:
Para perguntas sobre o suporte à falta de recursos, consulte as perguntas frequentes (Perguntas frequentes), nossos problemas abertos ou converse com usuários e desenvolvedores on -line no Zulip Community Server!
Recomendamos instalar em um ambiente virtual de Python dedicado (veja abaixo) ou usando uma opção automatizada como PIPX
Lançamentos estáveis - estes estão disponíveis no Pypi como o pacote zulip -termo
Para instalar, execute um comando como: pip3 install zulip-term
As versões mais recentes (Git) - a versão mais recente de desenvolvimento pode ser instalada no ramo main do Repositório Git
Para instalar, execute um comando como: pip3 install git+https://github.com/zulip/zulip-terminal.git@main
Também fornecemos alguns Dockerfiles de amostra para criar imagens do Docker no Docker/.
Com o Python 3.6+ necessário para a execução, o seguinte deve funcionar na maioria dos sistemas:
python3 -m venv zt_venv (cria um ambiente virtual chamado zt_venv no diretório atual)source zt_venv/bin/activate (ativa o ambiente virtual; isso assume uma concha semelhante a uma batida) Se você abrir uma janela de terminal diferente (ou fazer login/reiniciar seu computador), precisará executar a Etapa 2 da lista acima novamente antes de executar zulip-term , pois isso ativa esse ambiente virtual. Você pode ler mais sobre ambientes virtuais na documentação do Python 3 Library VENV.
Observe que não há sistema de atualização automática, por isso, rastreie os locais de atualização relevantes para sua versão de instalação:
Lançamentos estáveis
Antes de atualizar, recomendamos que você verifique as alterações nos lançamentos recentes para que você esteja ciente de quaisquer alterações importantes entre as versões.
Agora, eles são anunciados no tópico # Anunciar> Terminal libera o Zulip Community Server (https://chat.zulip.org), que é visível sem uma conta.
Se você deseja receber e -mails quando as atualizações forem anunciadas, poderá se inscrever para uma conta neste servidor, o que permitirá ativar notificações por email para o stream #Announce (artigo de ajuda, configurações de notificações no chat.zulip.org).
Você também pode personalizar a configuração do relógio do Github na página do projeto para incluir lançamentos.
O Pypi fornece um feed de liberação do RSS e vários outros serviços rastreiam essas informações.
Versões mais recentes (Git)
As versões instaladas na ramificação GIT main também não serão atualizadas automaticamente - o 'mais recente' refere -se ao status no ponto de instalação.
Isso também se aplica a outras instalações de origem ou desenvolvimento (por exemplo, https://aur.archlinex.org/packages/python-zulip-term-git/).
Portanto, atualize seu pacote usando o comando acima ou um pertinente ao seu sistema de pacotes (por exemplo, arco).
Embora a filial main visa permanecer estável, se a atualização entre duas versões arbitrárias de 'mais recentes', esteja ciente de que as alterações não estão resumidas , embora nosso log de confirmação deva ser muito legível.
Após a primeira execução zulip-term ele procura um arquivo zuliprc , por padrão no seu diretório inicial, que contém os detalhes para fazer login em um servidor Zulip.
Se não encontrar este arquivo, você terá duas opções:
zulip-term solicitará seu servidor, email e senha e criará um arquivo zuliprc para você nesse local
Nota: Se você usar o Google, o Github ou outra autenticação externa para acessar sua organização Zulip, provavelmente não terá um conjunto de senha e atualmente precisará criar um para usar o zulip-terminal.
<Zulip server URL>/accounts/password/reset/ para criar uma nova senha para sua conta (por exemplo: https://chat.zulip.org/accounts/password/reset/). Cada vez que você executa zulip-term , você pode especificar o caminho para um arquivo zuliprc alternativo usando as opções -c ou --config-file , por exemplo. $ zulip-term -c /path/to/zuliprc
Um arquivo .zuliprc correspondente à sua conta em um servidor Zulip específico pode ser baixado através de aplicativos da Web ou da área de trabalho conectados a esse servidor. Nas versões recentes, isso pode ser encontrado em suas configurações pessoais na seção de conta e privacidade , na chave da API como 'Mostrar/Alterar sua chave da API'.
Se esta for sua única conta Zulip, convém mover e renomear esse arquivo para o local do arquivo padrão acima ou renomeá-lo para algo mais memorável que você possa passar para a opção ---config-file . Este arquivo .zuliprc fornece todas as permissões que você tem como usuário.
.zuliprc files semelhantes podem ser baixados da seção BOTS para qualquer bots que você configurou, embora com permissões correspondentemente limitadas.
NOTA: Se o seu servidor usar certificados autoassinados ou uma conexão insegura, você precisará adicionar opções extras ao arquivo zuliprc manualmente - consulte a documentação para o módulo Zulip Python.
Sugerimos a execução zulip-term usando a opção -e ou --explore (no modo de exploração) quando você está tentando o terminal Zulip pela primeira vez, onde intencionalmente não marque as mensagens como lidas. Tente acompanhar o nosso tutorial para pegar o jeito das coisas.
O arquivo zuliprc contém duas seções:
[api] com informações necessárias para se conectar ao seu servidor Zulip[zterm] com configuração específica para zulip-term Um arquivo com apenas a primeira seção pode ser gerado automaticamente em alguns casos por zulip-term , ou você pode baixar um da sua conta no seu servidor (veja acima). Partes da segunda seção podem ser adicionadas e ajustadas em estágios quando você deseja personalizar o comportamento do zulip-term .
O exemplo abaixo, com o conteúdo da seção dummy [api] , representa um arquivo de configuração em funcionamento com todos os valores compatíveis padrão [zterm] não tomados e com notas que acompanham:
[api]
[email protected]
key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
site=https://example.zulipchat.com
[zterm]
## Theme: available themes can be found by running `zulip-term --list-themes`, or in docs/FAQ.md
theme=zt_dark
## Autohide: set to 'autohide' to hide the left & right panels except when they're focused
autohide=no_autohide
## Exit Confirmation: set to 'disabled' to exit directly with no warning popup first
exit_confirmation=enabled
## Footlinks: set to 'disabled' to hide footlinks; 'enabled' will show the first 3 per message
## For more flexibility, comment-out this value, and un-comment maximum-footlinks below
footlinks=enabled
## Maximum-footlinks: set to any value 0 or greater, to limit footlinks shown per message
# maximum-footlinks=3
## Notify: set to 'enabled' to display notifications (see elsewhere for configuration notes)
notify=disabled
## Color-depth: set to one of 1 (for monochrome), 16, 256, or 24bit
color-depth=256
## Transparency: set to 'enabled' to allow background transparency
## This is highly dependent on a suitable terminal emulator, and support in the selected theme
## Terminal emulators without this feature may show an arbitrary solid background color
transparency=disabled
## Editor: set external editor command, to edit message content
## If not set, this falls back to the $ZULIP_EDITOR_COMMAND then $EDITOR environment variables
# editor: nano
NOTA: A maioria dessas definições de configuração pode ser especificada na linha de comando quando
zulip-termfor iniciado;zulip-term -houzulip-term --helpfornecerá a lista completa de opções.
Observe que as notificações não são atualmente suportadas no WSL; Veja #767.
O comando a seguir instala notify-send em sistemas baseados em Debian, comandos semelhantes também podem ser encontrados para outros sistemas Linux.
sudo apt-get install libnotify-bin
Nenhum pacote adicional é necessário para ativar as notificações no OS X. No entanto, para ter um som de notificação, defina a seguinte variável (com base no seu tipo de shell). O valor sonoro (aqui ping) pode ser qualquer um dos arquivos .aiff encontrados em /System/Library/Sounds ou ~/Library/Sounds .
Bash
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.bash_profile
source ~/.bash_profile
Zsh
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.zshenv
source ~/.zshenv
O terminal Zulip permite que os usuários copam determinados textos para a área de transferência por meio de um módulo Python, Pyperclip . Este módulo utiliza vários pacotes do sistema que podem ou não vir com o sistema operacional. Atualmente, o recurso "cópia para a área de transferência" está disponível apenas para copiar o email do fluxo, no pop -up de informações do fluxo.
No Linux, este módulo utiliza os comandos xclip ou xsel , que já devem vir com o sistema operacional. Se nenhum desses comandos estiver instalado no seu sistema, instale alguém usando:
sudo apt-get install xclip [Recommended]
OU
sudo apt-get install xsel
Nenhum pacote adicional é necessário para permitir a cópia para a área de transferência.
Enquanto o terminal Zulip foi projetado para funcionar com qualquer servidor Zulip, os principais colaboradores estão presentes no Zulip Community Server em https://chat.zulip.org, com a maioria das conversas no fluxo #zulip-terminal .
Você pode ver as conversas nesse fluxo usando o link acima ou se inscrever em uma conta e conversar conosco - seja um usuário ou desenvolvedor!
Nosso objetivo é manter a comunidade Zulip amigável, acolhedora e produtiva; portanto, se estiver participando, respeite as normas da nossa comunidade.
Estes são um subconjunto das normas da comunidade vinculadas acima, que são mais relevantes para os usuários do terminal Zulip: aqueles com maior probabilidade de estar em um ambiente de texto, limitados em linhas/colunas de caracteres e presentes neste fluxo menor.
Prefira o texto em blocos de código, em vez de capturas de tela
O Terminal Zulip suporta baixar imagens, mas não há garantia de que os usuários possam visualizá -las.
Tente meta + m para ver exemplo de formatação de conteúdo, incluindo blocos de código
Prefira menções silenciosas sobre menções regulares - ou evitar menções inteiramente
Com os tópicos de Zulip, o destinatário pretendido já pode ser claro. Os membros experientes estarão presentes à medida que seu tempo permite - respondendo às mensagens quando retornar - e outros poderão ajudar antes disso.
(Salvar menções regulares para aqueles que você não espera estar presente regularmente)
Experimente Ctrl + F / B para percorrer a conclusão automática no conteúdo da mensagem, depois de digitar @_ para especificar uma menção silenciosa
Prefira cortar a citação e o texto de resposta apenas às partes relevantes de mensagens mais longas - ou evite citar totalmente
Os tópicos de Zulip geralmente deixam claro qual mensagem você está respondendo. Mensagens longas podem ser mais difíceis de ler com linhas e colunas limitadas de texto, mas isso é agravado se citando uma mensagem longa inteira com conteúdo extra.
Tente > citar uma mensagem selecionada, excluindo o texto normalmente ao compor uma mensagem
Prefira uma rápida reação emoji para mostrar concordância em vez de mensagens curtas simples
As reações ocupam menos espaço, inclusive no terminal Zulip, principalmente quando vários usuários desejam responder com o mesmo sentimento.
Tente + para alternar os polegares (+1) em uma mensagem ou usar : para pesquisar outras reações
O terminal Zulip está sendo construído pela incrível comunidade Zulip.
Para fazer parte dele e contribuir para o código, sinta-se à vontade para trabalhar em qualquer problema ou propor sua ideia no #Zulip-terminal.
Para uma estrutura e estilo de compromisso, revise a seção de estilo de confirmação abaixo.
Se você é novo no git (ou não!), Pode se beneficiar do Guia do Zulip Git. Ao contribuir, é importante observar que usamos um fluxo de trabalho orientado a rebase .
Um tutorial simples está disponível para implementar o indicador typing . Siga-o para entender como implementar um novo recurso para o zulip-terminal.
É claro que você pode navegar pela fonte no Github e na árvore de origem que você baixar e verificar a visão geral do arquivo de origem para obter idéias de como os arquivos estão dispostos atualmente.
O Terminal Zulip usa a URWID para renderizar os componentes da interface do usuário no terminal. O URWID é uma biblioteca incrível pela qual você pode renderizar uma interface do usuário decente apenas usando o Python. O tutorial de Urwid é um ótimo lugar para começar para novos colaboradores.
Primeiro, bifurcar o repositório zulip/zulip-terminal no Github (veja como) e clone o repositório bifurcado localmente, substituindo seu nome de nome pelo seu nome de usuário do github:
$ git clone --config pull.rebase [email protected]:YOUR_USERNAME/zulip-terminal.git
Isso deve criar um novo diretório para o repositório no diretório atual; portanto, digite o diretório do repositório com cd zulip-terminal e configure e busque o repositório remoto a montante para o seu garfo clonado do terminal Zulip:
$ git remote add -f upstream https://github.com/zulip/zulip-terminal.git
Para uma explicação detalhada dos comandos usados para clonagem e configuração a montante, consulte a Etapa 1 da seção Get Zulip Code do guia Git de Zulip.
Várias opções estão disponíveis; Estamos explorando os benefícios de cada um e apreciaríamos feedback sobre o qual você usa ou sente que funciona melhor.
Observe que as ferramentas usadas em cada caso são normalmente as mesmas, mas são chamadas de maneiras diferentes.
Os seguintes comandos devem ser executados no diretório do repositório, criados por um processo semelhante ao da seção anterior.
$ pip3 install --user pipenv
--python 3.6 para ser mais específico) $ pipenv --three
$ pipenv install --dev
$ pipenv run pip3 install -e '.[dev]'
$ pipenv run gitlint install-hook
Criar e ativar manualmente um ambiente virtual; Qualquer método deve funcionar, como o usado na instalação simples acima
python3 -m venv zt_venv (cria um venv chamado zt_venv no diretório atual)source zt_venv/bin/activate (ativa o venv; isso assume uma concha semelhante a uma festa)Instale o termo zulip, com os requisitos de desenvolvimento
$ pip3 install -e '.[dev]'
$ gitlint install-hook
Esta é a abordagem mais recente e mais simples, se você make instalar:
make (configura um ambiente virtual instalado em zt_venv no diretório atual)source zt_venv/bin/activate (ativa o venv; isso assume uma concha semelhante a uma festa)gitlint install-hook (conecte o gancho Gitlint Commit Message)Depois de configurar um ambiente de desenvolvimento, você pode achar o seguinte útil, dependendo do seu tipo de ambiente:
| Tarefa | Make & pip | Pipenv |
|---|---|---|
| Correr normalmente | zulip-term | pipenv run zulip-term |
| Execute no modo de depuração | zulip-term -d | pipenv run zulip-term -d |
| Corra com perfil | zulip-term --profile | pipenv run zulip-term --profile |
| Execute todos os linters | ./tools/lint-all | pipenv run ./tools/lint-all |
| Execute todos os testes | pytest | pipenv run pytest |
| Construir relatório de cobertura de teste | pytest --cov-report html:cov_html --cov=./ | pipenv run pytest --cov-report html:cov_html --cov=./ |
Se estiver usando o make with pip, a execução make garantirá que o ambiente de desenvolvimento esteja atualizado com as dependências especificadas, úteis após a busca do Git e Rebasing.
Escolha seu editor de texto favorito ou ambiente de desenvolvimento!
A fonte inclui um arquivo .editorconfig que permite que muitos editores se configurem automaticamente para produzir arquivos que atendam aos requisitos mínimos para o projeto. Consulte https://editorconfig.org para suporte ao editor; Observe que alguns podem exigir plugins, se você deseja usar esse recurso.
Os liners e testes automatizados (Pytest) são executados automaticamente em IC (Ações do GitHub) quando você envia uma solicitação de tração (PR) ou empurre alterações para uma solicitação de tração existente.
No entanto, a execução dessas verificações no seu computador pode acelerar seu desenvolvimento, evitando a necessidade de empurrar seu código repetidamente para o Github. Os comandos para conseguir isso estão listados na tabela de tarefas de desenvolvimento acima (os linters individuais também podem ser executados via scripts nas tools/ ).
Além disso, se estiver usando um sistema baseado make :
make lint e make test executar todo o grupo de cada grupo de tarefasmake check -as de todas as verificações, o que é útil antes de pressionar um PR (ou uma atualização)tools/check-branch fará make check em cada compromisso em sua filialNota: É altamente improvável que uma solicitação de tração seja mesclada, até que todos os linheiros e testes estejam passando, inclusive por comissão.
A correção de alguns erros de linha requer intervenção manual, como do mypy para verificação do tipo.
Para obter dicas sobre o teste, revise a seção mais abaixo sobre o Pytest.
No entanto, outros erros de linha podem ser corrigidos automaticamente, conforme detalhado abaixo - isso pode economizar muito tempo ajustando manualmente seu código para passar os linheiros!
Se você tiver problemas para entender por que os linheiros ou pytest estão falhando, empurre seu código para uma ramificação/PR e podemos discutir os problemas no PR ou no chat.zulip.org.
Se você os atualizar, observe que não precisará atualizar o texto em ambos os lugares manualmente para passar o revestimento.
A fonte da verdade está no código -fonte; portanto, atualize o arquivo python e execute a ferramenta relevante. Atualmente temos:
tools/lint-hotkeys --fix para regenerar docs/hotkeys.md de config/keys.pytools/lint-docstring --fix para regenerar Docs/Developer-File-Overview.md de File Docstrings(Essas ferramentas também são usadas para o processo de linha, para garantir que esses arquivos sejam sincronizados)
O projeto usa black e isort para o estilo de código e a classificação de importação, respectivamente.
Essas ferramentas podem ser executadas como linters localmente, mas também podem formatar seu código automaticamente para você.
Se você estiver usando uma configuração baseada make , a execução make fix será executada (e algumas outras ferramentas) e reformate o estado atual do seu código -então você deseja se comprometer primeiro por precaução, então --amend esse comprometimento se você estiver satisfeito com as alterações.
Você também pode usar as ferramentas individualmente em um arquivo ou diretório, por exemplo. black zulipterminal ou isort tests/model/test_model.py
Enquanto você trabalha localmente, investigando alterações a fazer, é comum fazer uma série de pequenas confirmações para armazenar seu progresso. Muitas vezes, isso pode incluir commits que corrigem problemas de linha ou teste no (s) comprometimento (s) anterior (s). Essas são commits de estilo de desenvolvimento - e quase todo mundo provavelmente escreverá compromissos nesse estilo até certo ponto.
Cometidos de estilo de desenvolvimento armazenam as mudanças muito bem para você agora. No entanto, ao compartilhar seu código, as mensagens comprometidas são um ótimo lugar para se comunicar aos outros o que você está mudando e por quê. Ter a estrutura também pode tornar mais fácil e rápido o leitor entender as mudanças e que você respeita o tempo deles. Um exemplo é que compromissos single muito grandes podem levar muito tempo para revisar, em comparação se forem divididos. Outra é se você corrigir os testes/linhagem em uma confirmação: qual compromete (ou cometidos!), Isso corrige, e se estiver na mesma ramificação/PR, por que a confirmação original não é corrigida?
Portanto, ao criar uma solicitação de tração (PR), considere que seu código tem maior probabilidade de ser mesclado, mais rapidamente, se for mais fácil ler, entender e revisar - e uma grande parte disso é como você estrutura suas alterações nas commits e descreve essas mudanças nas mensagens de confirmação.
Para ser produtivo e facilitar a revisão e atualização do seu PRS, seguimos uma abordagem adotada em Zulip e em outros lugares, buscando o PRS consistir em uma série de compromissos mínimos coerentes :
Observe que manter esses princípios pode dar outros benefícios, antes, durante e depois de revisar um PR, incluindo:
git bisect em sua filial ou em main Agora, aplicamos um aspecto limitado da natureza coerente dos compromissos em um PR em um trabalho como parte de nossa integração contínua (IC), garantem que os compromissos isolados de relações públicas , que essencialmente executam make check de cada confirmação em sua filial. Você pode replicar isso localmente antes de pressionar para o GitHub usando tools/check-branch .
Embora os PRs pequenos ou de prova de conceito sejam inicialmente bons de empurrar, eles provavelmente serão revisados apenas com base nas alterações gerais. Geralmente, se os compromissos individuais parecem ter um estilo de desenvolvimento, é provável que os revisores forneçam um feedback menos específico, e os compromissos mínimos coerentes certamente serão solicitados antes da fusão.
Comandos de reestruturação - A maioria de reestruturação depende da rebase interativa (por exemplo, git rebase -i upstream/main ), mas considere pesquisar on -line ações específicas, além de pesquisar ou pedir ajuda #git ou #learning no chat.zulip.org.
Auto -revisão - Outra abordagem útil é revisar suas próprias compromissos localmente (consulte as sugestões de Zulip) e depois de pressionar para o Github. Isso permite que você inspecione e corrija qualquer coisa que pareça deslocada, que alguém provavelmente pegará em sua revisão, ajudando seus envios a parecer mais polidos, além de indicar novamente que você respeita o tempo dos revisores.
Nosso objetivo é seguir um estilo de confirmação padrão para manter o git log consistente e fácil de ler.
Assim como trabalhar com código, sugerimos que você se refira a compromissos recentes no log do Git, para exemplos do estilo que estamos usando ativamente.
Nosso estilo geral para cometer mensagens segue amplamente as diretrizes gerais fornecidas para as mensagens Zulip Commit, por isso recomendamos ler isso primeiro.
Nossos títulos de comprometimento (resumos) têm pequenas variações do estilo zulip em geral, com cada um:
/Tests updated ou Tests added no texto de comprometimento)refactor: , bugfix: e requirements: (veja abaixo)Alguns exemplos de comprometimento de títulos: (idealmente mais descritivos na prática!)
file3/file1/file2: Improve behavior of something.file1.txt , file2.py e file3.mdrefactor: file1/file2: Extract some common function.file1.py e file2.pybugfix: file1: Avoid some noticeable bug.file1.pytests: file1: Improve test for something.file1 , provavelmente em test_file1.pyrequirements: Upgrade some-dependency from ==9.2 to ==9.3. Para ajudar a satisfazer algumas dessas regras, você pode usar GitLint , conforme descrito na seção a seguir.
No entanto , verifique suas confirmações manualmente versus essas regras de estilo, pois o Gitlint não pode verificar tudo - incluindo idioma ou gramática!
A ferramenta gitlint é instalada por padrão no ambiente de desenvolvimento e pode ajudar a garantir que seus compromissos atendam ao padrão esperado.
A ferramenta pode verificar as confirmações específicas manualmente, por exemplo. gitlint para o mais recente compromisso, ou gitlint --commits main.. Para compromissos que lideram de main . No entanto, é altamente recomendável executar gitlint install-hook para instalar o gancho de message gitlint (ou pipenv run gitlint install-hook com configurações PIPENV).
Se o gancho for instalado como descrito acima, depois de concluir o texto para uma confirmação, ele será verificado por Gitlint com o estilo que configuramos e oferecerá conselhos se houver algum problema que ele avisasse. Se o Gitlint encontrar algum, ele perguntará se você deseja cometer com a mensagem como é ( y para 'sim'), pare o processo de confirmação ( n para 'não') ou edite a mensagem de confirmação ( e para 'editar').
Embora o conteúdo ainda dependa de suas habilidades de escrita, isso garante uma estrutura de formatação mais consistente entre os compromissos, inclusive por diferentes autores.
Os testes para zulip-terminal são escritos usando pytest. Você pode ler os testes na pasta /tests para aprender sobre a gravação de testes para uma nova classe /função. Se você é novo no Pytest, a leitura de sua documentação é definitivamente recomendada.
Atualmente, temos milhares de testes que são verificados ao executar pytest . Embora dependa da capacidade do seu sistema, isso geralmente deve levar menos de um minuto para ser executado. No entanto, durante a depuração, você ainda deseja limitar o escopo de seus testes, para melhorar o tempo de resposta:
Se muitos testes estiverem falhando de uma maneira muito detalhada, você poderá tentar a opção -x (por exemplo, pytest -x ) para interromper os testes após a primeira falha; Devido à parametrização de testes e acessórios de teste, muitos erros/falhas aparentes podem ser resolvidos com apenas uma correção! (Tente por exemplo. pytest --maxfail 3 para uma versão menos rica disso)
Para evitar executar todos os testes bem-sucedidos a cada vez, juntamente com as falhas, você pode executar com --lf (por exemplo, pytest --lf ), curto para --last-failed (opções úteis semelhantes podem ser --failed-first e --new-first , que podem funcionar bem com -x )
Como o Pytest 3.10 existe --sw ( --stepwise ), que funciona através de falhas conhecidas da mesma maneira que --lf e -x podem ser usadas, que podem ser combinadas com --stepwise-skip para controlar qual teste é o foco atual
Se você souber os nomes dos testes que estão falhando e/ou em um local específico, poderá limitar os testes a um local específico (por exemplo, pytest tests/model ) ou usar uma palavra -chave selecionada (por exemplo, pytest -k __handle )
Quando apenas um subconjunto de testes está em execução, ele se torna mais prático e útil para usar a opção -v ( --verbose ); em vez de mostrar um . (ou F , E , x , etc) Para cada resultado do teste, ele fornece o nome (com parâmetros de cada teste sendo executado (por exemplo, pytest -v -k __handle ). Esta opção também mostra mais detalhes nos testes e pode ser fornecida várias vezes (por exemplo, pytest -vv ).
Para obter ajuda adicional com opções de pytest, consulte pytest -h ou confira a documentação completa do pytest.
print O stdout (saída padrão) para zulip-terminal é redirecionado para ./debug.log se a depuração for ativada em tempo de execução usando -d ou --debug .
Isso significa que, se você deseja verificar o valor de uma variável, ou talvez indique atingir um certo ponto no código, você pode simplesmente usar print() , por exemplo.
print ( f"Just about to do something with { variable } " ) E ao executar com uma opção de depuração, a string será impressa para ./debug.log .
Com um terminal semelhante ao Bash, você pode executar algo como tail -f debug.log em outro terminal, para ver a saída da print à medida que acontece.
Se você deseja depurar o zulip-terminal enquanto estiver sendo executado ou em um estado específico, você pode inserir
from pudb . remote import set_trace
set_trace () Na parte do código que você deseja depurar. Isso iniciará uma conexão Telnet para você. Você pode encontrar o endereço IP e a porta da conexão Telnet em ./debug.log . Em seguida, basta correr
$ telnet 127.0.0.1 6899
Em outro terminal, onde 127.0.0.1 é o endereço IP e 6899 é a porta que você encontra em ./debug.log .
Isso provavelmente significa que você instalou versões normais e de desenvolvimento do terminal zulip.
Para garantir que você execute a versão de desenvolvimento:
Se estiver usando PIPENV, ligue para pipenv run zulip-term do diretório zulip-terminal clonado/baixado;
Se estiver usando PIP (PIP3), verifique se você ativou o ambiente virtual correto (VENV); Dependendo de como o seu shell está configurado, o nome do VENV pode aparecer no prompt de comando. Observe que não incluir o -e no comando PIP3 também causará esse problema.
