zulip terminal
Zulip Terminal 0.7.0
Cambios recientes | Configuración | Llaves calientes | Preguntas frecuentes | Desarrollo | Tutorial
Zulip Terminal es el cliente terminal oficial para Zulip, que proporciona una interfaz de usuario basada en texto (TUI).
Los objetivos específicos incluyen:
Aprenda a usar Zulip Terminal con nuestro tutorial.
Consideramos que el cliente ya proporciona una experiencia bastante estable moderadamente característica de los usuarios cotidianos.
El enfoque de desarrollo actual es mejorar los aspectos del uso cotidiano que se usan más comúnmente para reducir la necesidad de que los usuarios cambien temporalmente a otro cliente para una característica particular.
Las limitaciones actuales que esperamos solo resolver a largo plazo incluyen soporte para:
El cliente terminal actualmente tiene una serie de diferencias intencionales con el cliente web Zulip:
Para consultas sobre el soporte de funciones faltantes, eche un vistazo a las preguntas frecuentes (preguntas frecuentes), nuestros problemas abiertos o chatear con usuarios y desarrolladores en línea en el servidor de la comunidad Zulip.
Recomendamos instalar en un entorno virtual de Python dedicado (ver más abajo) o usar una opción automatizada como PIPX
Lanzamientos estables : estas están disponibles en Pypi como el paquete zulip -término
Para instalar, ejecute un comando como: pip3 install zulip-term
Versiones más recientes (GIT) : la última versión de desarrollo se puede instalar desde la rama main del repositorio de git
Para instalar, ejecute un comando como: pip3 install git+https://github.com/zulip/zulip-terminal.git@main
También proporcionamos algunas muestras de DockerFiles para construir imágenes de Docker en Docker/.
Con el Python 3.6+ requerido para ejecutar, lo siguiente debería funcionar en la mayoría de los sistemas:
python3 -m venv zt_venv (crea un entorno virtual llamado zt_venv en el directorio actual)source zt_venv/bin/activate (activa el entorno virtual; esto supone un shell similar a Bash) Si abre una ventana de terminal diferente (o registra/reinicia su computadora), deberá ejecutar el Paso 2 de la lista anterior nuevamente antes de ejecutar zulip-term , ya que eso activa ese entorno virtual. Puede leer más sobre entornos virtuales en la documentación de Venv de la Biblioteca Python 3.
Tenga en cuenta que no hay un sistema de actualización automática, así que rastree las ubicaciones de actualización relevantes para su versión de instalación:
Lanzamientos estables
Antes de actualizar, le recomendamos que verifique los cambios en las versiones recientes para que tenga en cuenta cualquier cambio importante entre las versiones.
Estos ahora se anuncian en el tema # Anuncio> Terminal liberan en el servidor de la comunidad Zulip (https://chat.zulip.org), que es visible sin una cuenta.
Si desea recibir correos electrónicos cuando se anuncian las actualizaciones, puede registrarse en una cuenta en este servidor, que le permitirá habilitar las notificaciones de correo electrónico para el flujo #Annebe (artículo de ayuda, configuración de notificaciones en chat.zulip.org).
También puede personalizar su configuración de reloj GitHub en la página del proyecto para incluir lanzamientos.
PYPI proporciona una feed de lanzamiento RSS, y varios otros servicios rastrean esta información.
Últimas versiones (git)
Las versiones instaladas desde la rama GIT main tampoco se actualizarán automáticamente: el 'último' se refiere al estado en el punto de instalación.
Esto también se aplica a otras instalaciones de origen o desarrollo (por ejemplo, https://aur.archlinux.org/packages/python-zulip-term-git/).
Por lo tanto, actualice su paquete utilizando el comando anterior, o uno pertinente para su sistema de paquete (por ejemplo, Arch).
Si bien la rama main está destinada a permanecer estable, si se actualiza entre dos versiones arbitrarias 'más recientes', tenga en cuenta que no se resumen los cambios , aunque nuestro registro de confirmación debe ser muy legible.
Al ejecutar primero zulip-term busca un archivo zuliprc , de forma predeterminada en su directorio de inicio, que contiene los detalles para iniciar sesión en un servidor Zulip.
Si no encuentra este archivo, tiene dos opciones:
zulip-term lo solicitará su servidor, correo electrónico y contraseña, y creará un archivo zuliprc para usted en esa ubicación
Nota: Si usa Google, GitHub u otra autenticación externa para acceder a su organización Zulip, entonces es probable que no tenga un conjunto de contraseñas y actualmente necesite crear uno para usar Zulip-terminal.
<Zulip server URL>/accounts/password/reset/ para crear una nueva contraseña para su cuenta (por ejemplo: https://chat.zulip.org/accounts/password/reset/). Cada vez que ejecuta zulip-term , puede especificar la ruta a un archivo zuliprc alternativo utilizando las opciones -c o --config-file , por ejemplo. $ zulip-term -c /path/to/zuliprc
Un archivo .zuliprc correspondiente a su cuenta en un servidor Zulip particular se puede descargar a través de aplicaciones web o de escritorio conectadas a ese servidor. En versiones recientes, esto se puede encontrar en su configuración personal en la sección de cuenta y privacidad , en la clave API como 'Mostrar/cambiar su clave API'.
Si esta es su única cuenta de Zulip, es posible que desee mover y cambiar el nombre de este archivo a la ubicación de archivo predeterminada anterior, o cambiarla a algo más memorable que pueda pasar a la opción ---config-file . Este archivo .zuliprc le brinda todos los permisos que tiene como usuario.
Se pueden descargar .zuliprc files similares de la sección BOTS para cualquier bots que haya configurado, aunque con permisos correspondientemente limitados.
Nota: Si su servidor usa certificados autofirmados o una conexión insegura, deberá agregar opciones adicionales al archivo zuliprc manualmente; consulte la documentación del módulo Zulip Python.
Sugerimos ejecutar zulip-term usando la opción -e o --explore (en modo de exploración) cuando intenta Zulip Terminal por primera vez, donde intencionalmente no marcamos los mensajes como leídos. Intente seguir junto con nuestro tutorial para dominar las cosas.
El archivo zuliprc contiene dos secciones:
[api] con información requerida para conectarse a su servidor Zulip[zterm] con configuración específica para zulip-term Un archivo con solo la primera sección se puede generar automáticamente en algunos casos por zulip-term , o puede descargar uno desde su cuenta en su servidor (ver arriba). Partes de la segunda sección se pueden agregar y ajustar en etapas cuando desea personalizar el comportamiento del zulip-term .
El ejemplo a continuación, con contenido de la sección Dummy [api] , representa un archivo de configuración de trabajo con todos los valores compatibles predeterminados [zterm] incommentados y con notas adjuntas:
[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: La mayoría de estos ajustes de configuración se pueden especificar en la línea de comando cuando se inicia
zulip-term;zulip-term -hozulip-term --helpdará la lista completa de opciones.
Tenga en cuenta que las notificaciones no son compatibles actualmente en WSL; Ver #767.
El siguiente comando instala notify-send de sistemas basados en Debian, también se pueden encontrar comandos similares para otros sistemas Linux.
sudo apt-get install libnotify-bin
No se requiere un paquete adicional para habilitar notificaciones en OS X. Sin embargo, para tener un sonido de notificación, establezca la siguiente variable (según su tipo de shell). El valor de sonido (aquí ping) puede ser cualquiera de los archivos .aiff encontrados en /System/Library/Sounds o ~/Library/Sounds .
Intento
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.bash_profile
source ~/.bash_profile
Zsh
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.zshenv
source ~/.zshenv
Zulip Terminal permite a los usuarios copiar ciertos textos al portapapeles a través de un módulo Python, Pyperclip . Este módulo utiliza varios paquetes de sistema que pueden o no venir con el sistema operativo. La función "Copiar al portapapeles" actualmente solo está disponible para copiar el correo electrónico de transmisión, desde la ventana emergente de información de transmisión.
En Linux, este módulo utiliza los comandos xclip o xsel , que ya deberían venir con el sistema operativo. Si ninguno de estos comandos está instalado en su sistema, instale a cualquiera usando:
sudo apt-get install xclip [Recommended]
O
sudo apt-get install xsel
No se requiere un paquete adicional para habilitar la copia al portapapeles.
Si bien Zulip Terminal está diseñado para funcionar con cualquier servidor Zulip, los principales contribuyentes están presentes en el servidor de la comunidad Zulip en https://chat.zulip.org, con la mayoría de la conversación en la transmisión #Zulip-terminal .
Puede ver las conversaciones en esa transmisión utilizando el enlace de arriba, o regístrese para una cuenta y chatear con nosotros, ¡ya sea un usuario o desarrollador!
Nuestro objetivo es mantener la comunidad zulip amigable, acogedora y productiva, por lo que si participa, respeta las normas de nuestra comunidad.
Estas son un subconjunto de las normas de la comunidad vinculadas anteriormente, que son más relevantes para los usuarios de la terminal Zulip: las más propensas a estar en un entorno de texto, limitados en filas/columnas de caracteres y están presentes en esta transmisión más pequeña.
Prefiere el texto en bloques de código, en lugar de capturas de pantalla
Zulip Terminal admite la descarga de imágenes, pero no hay garantía de que los usuarios puedan verlas.
Pruebe Meta + M para ver el formato de contenido de ejemplo, incluidos los bloques de código
Prefiere menciones silenciosas sobre menciones regulares, o evite las menciones por completo
Con los temas de Zulip, el destinatario previsto a menudo puede ser claro. Los miembros experimentados estarán presentes según su tiempo, respondiendo a los mensajes cuando regresen, y otros pueden ayudar antes de eso.
(Ahorre menciones regulares para aquellos a quienes no espera estar presentes de manera regular)
Pruebe con CTRL + F / B para recorrer automáticamente a través de AutoCompletion en el contenido del mensaje, después de escribir @_ para especificar una mención silenciosa
Prefiere recortar cita y responder texto solo a las partes relevantes de mensajes más largos, o evite citar por completo
Los temas de Zulip a menudo dejan en claro a qué mensaje está respondiendo. Los mensajes largos pueden ser más difíciles de leer con filas y columnas de texto limitadas, pero esto empeora si cita un mensaje largo con contenido adicional.
Pruebe > para citar un mensaje seleccionado, eliminando el texto de manera normal al componer un mensaje
Prefiere una reacción de emoji rápida para mostrar un acuerdo en lugar de mensajes cortos simples
Las reacciones ocupan menos espacio, incluso en la terminal Zulip, particularmente cuando múltiples usuarios desean responder con el mismo sentimiento.
Pruebe + para alternar los pulgares (+1) en un mensaje, o usar : para buscar otras reacciones
Zulip Terminal está siendo construido por la increíble comunidad de zulip.
Para ser parte de él y contribuir al código, no dude en trabajar en cualquier tema o proponer su idea en #Zulip-terminal.
Para la estructura y el estilo de confirmación, revise la sección de estilo de confirmación a continuación.
Si eres nuevo en git (¡o no!), Puede beneficiarse de la guía Zulip Git. Al contribuir, es importante tener en cuenta que usamos un flujo de trabajo orientado a Rebase .
Un tutorial simple está disponible para implementar el indicador typing . Siga para comprender cómo implementar una nueva característica para Zulip-terminal.
Por supuesto, puede navegar por la fuente en GitHub y en el árbol de origen que descargue, y verificar la descripción general del archivo de origen para obtener ideas de cómo se organizan los archivos actualmente.
Zulip Terminal usa Urwid para representar los componentes de la UI en la terminal. Urwid es una biblioteca impresionante a través de la cual puedes representar una interfaz de usuario terminal decente que solo usa Python. El tutorial de Urwid es un gran lugar para comenzar para nuevos contribuyentes.
Primero, bifurca el repositorio zulip/zulip-terminal en GitHub (vea cómo) y luego clone su repositorio bifurcado localmente, reemplazando su_username con su nombre de usuario GitHub:
$ git clone --config pull.rebase [email protected]:YOUR_USERNAME/zulip-terminal.git
Esto debería crear un nuevo directorio para el repositorio en el directorio actual, así que ingrese el directorio de repositorio con cd zulip-terminal y configure y obtenga el repositorio remoto ascendente para su horquilla clonada de terminal Zulip:
$ git remote add -f upstream https://github.com/zulip/zulip-terminal.git
Para obtener una explicación detallada sobre los comandos utilizados para la clonación y la configuración ascendente, consulte el Paso 1 de la sección GET ZULIP CODE de la guía GIT de Zulip.
Hay varias opciones disponibles; Estamos explorando los beneficios de cada uno y apreciaríamos los comentarios sobre los que usa o siente que funciona mejor.
Tenga en cuenta que las herramientas utilizadas en cada caso son típicamente las mismas, pero se llaman de diferentes maneras.
Los siguientes comandos deben ejecutarse en el directorio de repositorio, creado por un proceso similar al de la sección anterior.
$ pip3 install --user pipenv
--python 3.6 para ser más específico) $ pipenv --three
$ pipenv install --dev
$ pipenv run pip3 install -e '.[dev]'
$ pipenv run gitlint install-hook
Crear y activar manualmente un entorno virtual; Cualquier método debería funcionar, como el utilizado en la instalación simple anterior
python3 -m venv zt_venv (crea un venv llamado zt_venv en el directorio actual)source zt_venv/bin/activate (activa el venv; esto supone una carcasa similar a la fiesta)Instale el término zulipal, con los requisitos de desarrollo
$ pip3 install -e '.[dev]'
$ gitlint install-hook
Este es el enfoque más nuevo y simple, si ha make :
make (establece un entorno virtual instalado en zt_venv en el directorio actual)source zt_venv/bin/activate (activa el venv; esto supone una carcasa similar a la fiesta)gitlint install-hook (conecte el gancho de gitlint commit-message)Una vez que tenga un entorno de desarrollo configurado, puede encontrar lo siguiente útil, dependiendo de su tipo de entorno:
| Tarea | Hacer y pip | Pipenv |
|---|---|---|
| Correr normalmente | zulip-term | pipenv run zulip-term |
| Ejecutar en modo de depuración | zulip-term -d | pipenv run zulip-term -d |
| Correr con perfiles | zulip-term --profile | pipenv run zulip-term --profile |
| Ejecutar todas las líneas | ./tools/lint-all | pipenv run ./tools/lint-all |
| Ejecutar todas las pruebas | pytest | pipenv run pytest |
| Informe de cobertura de prueba de compilación | pytest --cov-report html:cov_html --cov=./ | pipenv run pytest --cov-report html:cov_html --cov=./ |
Si usa Make With PIP, Running make asegurará que el entorno de desarrollo esté actualizado con las dependencias especificadas, útil después de obtener de GIT y Rebasing.
¡Elija su editor de texto o entorno de desarrollo favorito!
La fuente incluye un archivo .editorconfig que permite a muchos editores configurarse automáticamente para producir archivos que cumplan con los requisitos mínimos para el proyecto. Ver https://editorconfig.org para el soporte del editor; Tenga en cuenta que algunos pueden requerir complementos si desea usar esta función.
Las revestimientos y las pruebas automatizadas (PYTEST) se ejecutan automáticamente en CI (acciones de GitHub) cuando envía una solicitud de extracción (PR) o empuja los cambios a una solicitud de extracción existente.
Sin embargo, ejecutar estas verificaciones en su computadora puede acelerar su desarrollo evitando la necesidad de empujar repetidamente su código a GitHub. Los comandos para lograr esto se enumeran en la tabla de tareas de desarrollo anteriores (los revestimientos individuales también se pueden ejecutar a través de scripts en tools/ ).
Además, si usa un sistema basado en make :
make lint y make test ejecute todos cada grupo de tareasmake check ejecuta todas las comprobaciones, lo cual es útil antes de presionar un PR (o una actualización)tools/check-branch se ejecutará make check en cada confirmación en su ramaNota: Es muy poco probable que se fusione una solicitud de extracción, hasta que pasen todas las líneas y pruebas, incluso por compromiso.
Corregir algunos errores de pelusa requiere una intervención manual, como de mypy para verificar el tipo.
Para obtener consejos sobre pruebas, revise la sección más a continuación con respecto a Pytest.
Sin embargo, otros errores de pelusa se pueden solucionar automáticamente, como se detalla a continuación: ¡esto puede ahorrar mucho tiempo ajustando manualmente su código para pasar las revestimientos!
Si tiene problemas para comprender por qué las revestimientos o pytest están fallando, empuje su código a una rama/PR y podemos discutir los problemas en el PR o en el chat.zulip.org.
Si actualiza estos, tenga en cuenta que no necesita actualizar el texto en ambos lugares manualmente para pasar la pelusa.
La fuente de la verdad está en el código fuente, así que simplemente actualice el archivo de Python y ejecute la herramienta relevante. Actualmente tenemos:
tools/lint-hotkeys --fix para regenerar documentos/hotkeys.md de config/keys.pytools/lint-docstring --fix para regenerar docs/desarrollador-archivo-overview.md de los documentos de archivos(Estas herramientas también se utilizan para el proceso de pelusa, para garantizar que estos archivos estén sincronizados)
El proyecto usa black e isort para la clasificación de estilo e importación respectivamente.
Estas herramientas se pueden ejecutar como revestimientos localmente, pero también pueden formatear automáticamente su código para usted.
Si está utilizando una configuración basada en make , Running make fix ejecutará tanto (y algunas otras herramientas) y reformatear el estado actual de su código, por lo que querrá comprometerse primero en caso de que, --amend ese compromiso si está contento con los cambios.
También puede usar las herramientas individualmente en un archivo o directorio, por ejemplo. black zulipterminal o isort tests/model/test_model.py
A medida que trabaja localmente, investigando los cambios para hacer, es común hacer una serie de pequeños compromisos para almacenar su progreso. A menudo, esto puede incluir compromisos que solucionan problemas de pelucas o pruebas en los compromisos anteriores. Estos son compromisos de estilo de desarrollo , y es probable que casi todos escriban compromisos en este estilo hasta cierto punto.
Las cometas de estilo de desarrollo almacenan los cambios bien para usted en este momento. Sin embargo, al compartir su código, los mensajes de confirmación son un excelente lugar para comunicarse con los demás lo que está cambiando y por qué. Ordenar la estructura también puede hacer que sea más fácil y rápido para un lector comprender los cambios, y que respeta su tiempo. Un ejemplo es que las confirmaciones individuales muy grandes pueden llevar mucho tiempo para revisar, en comparación con si se dividen. Otra es si arregla las pruebas/pelusas en un confirmación: ¡qué confirmación (o cometida!) Se arregla esto, y si está en la misma rama/PR, ¿por qué no se soluciona la confirmación original?
Por lo tanto, al crear una solicitud de extracción (PR), considere que es más probable que su código se fusione, más rápidamente, si es más fácil leer, comprender y revisar , y una gran parte de eso es cómo estructura sus cambios en compromisos y describe esos cambios en los mensajes de confirmación.
Para ser productivo y facilitar que su PRS sea revisado y actualizado, seguimos un enfoque adoptado en Zulip y en otros lugares, con el objetivo de que los PRS consistan en una serie de compromisos mínimos coherentes :
Tenga en cuenta que mantener estos principios puede dar otros beneficios, tanto antes, durante y después de revisar un PR, que incluye:
git bisect en su rama o en main Ahora hacemos cumplir un aspecto limitado de la naturaleza coherente de los compromisos en un PR en un trabajo como parte de nuestra integración continua (CI), asegurar que los compromisos de relaciones públicas aisladas , que se ejecutan esencialmente, make check cada compromiso en su rama. Puede replicar esto localmente antes de presionar a GitHub utilizando tools/check-branch .
Si bien los PR pequeños o de prueba de concepto están inicialmente bien para impulsar como son, es probable que solo se revisen en función de los cambios generales. En general, si los compromisos individuales parecen tener un estilo de desarrollo, entonces es probable que los revisores den comentarios menos específicos, y se solicitarán comodidades coherentes mínimas que se solicitarán antes de fusionarse.
Comandos de reestructuración : la mayoría de la reestructuración se basa en la rebase interactiva (por ejemplo, git rebase -i upstream/main ), pero considere buscar acciones específicas en línea, así como buscar o preguntar en #GIT Help o #learning en chat.zulip.org.
Auto revisión : otro enfoque útil es revisar sus propios compromisos localmente (ver sugerencias de zulip) y después de presionar a GitHub. Esto le permite inspeccionar y arreglar cualquier cosa que se vea fuera de lugar, que es probable que alguien capte en su revisión, ayudando a sus presentaciones a parecer más pulidos, y nuevamente indicando que respeta el tiempo de los revisores.
Nuestro objetivo es seguir un estilo de confirmación estándar para mantener el git log consistente y fácil de leer.
Al igual que trabajar con el código, le sugerimos que se refiera a los compromisos recientes en el registro GIT, para ver ejemplos del estilo que estamos utilizando activamente.
Nuestro estilo general para mensajes de confirmación sigue ampliamente las pautas generales dadas para los mensajes de confirmación de zulip, por lo que recomendamos leer eso primero.
Nuestros títulos de confirmación (resúmenes) tienen ligeras variaciones del estilo de zulipia general, con cada uno:
/Tests updated o Tests added en el texto de confirmación)refactor: , bugfix: y requirements: (ver más abajo)Algunos títulos de ejemplo de ejemplo: (¡idealmente más descriptivo en la práctica!)
file3/file1/file2: Improve behavior of something.file1.txt , file2.py y file3.mdrefactor: file1/file2: Extract some common function.file1.py y file2.pybugfix: file1: Avoid some noticeable bug.file1.pytests: file1: Improve test for something.file1 , probablemente en test_file1.pyrequirements: Upgrade some-dependency from ==9.2 to ==9.3. Para ayudar a satisfacer algunas de estas reglas, puede usar GitLint , como se describe en la siguiente sección.
Sin embargo , consulte sus compromisos manualmente versus estas reglas de estilo, ya que Gitlint no puede verificar todo, ¡incluido el idioma o la gramática!
La herramienta gitlint se instala de forma predeterminada en el entorno de desarrollo y puede ayudar a garantizar que sus compromisos cumplan con el estándar esperado.
La herramienta puede verificar comodidades específicas manualmente, por ejemplo. gitlint para el último Commit, o gitlint --commits main.. para Compromisos que conducen desde main . Sin embargo, recomendamos encarecidamente ejecutar gitlint install-hook para instalar el gancho gitlint Commit-Message (o pipenv run gitlint install-hook con configuraciones de Pipenv).
Si el gancho se instala como se describe anteriormente, luego de completar el texto para una confirmación, Gitlint lo verificará con el estilo que hemos configurado, y ofrecerá consejos si hay algún problema que no se dé cuenta. Si Gitlint encuentra alguno, preguntará si desea comprometerse con el mensaje como es ( y para 'sí'), detener el proceso de confirmación ( n para 'no') o editar el mensaje de confirmación ( e para 'editar').
Si bien el contenido aún depende de sus habilidades de escritura, esto garantiza una estructura de formato más consistente entre los compromisos, incluso por diferentes autores.
Las pruebas para Zulip-terminal se escriben usando Pytest. Puede leer las pruebas en la carpeta /tests para aprender sobre las pruebas de escritura para una nueva clase /función. Si es nuevo en Pytest, definitivamente se recomienda leer su documentación.
Actualmente tenemos miles de pruebas que se verifican al ejecutar pytest . Si bien depende de la capacidad de su sistema, esto generalmente debería tardar menos de un minuto en funcionar. Sin embargo, durante la depuración, es posible que desee limitar el alcance de sus pruebas, para mejorar el tiempo de respuesta:
Si muchas pruebas están fallando de una manera muy detallada, puede probar la opción -x (por ejemplo, pytest -x ) para detener las pruebas después de la primera falla; Debido a la parametrización de las pruebas y los accesorios de prueba, ¡muchos errores/fallas aparentes se pueden resolver con solo una solución! (Prueba, por ejemplo, pytest --maxfail 3 para una versión menos estricta de esto)
Para evitar ejecutar todas las pruebas exitosas cada vez, junto con las fallas, puede ejecutar con --lf (por ejemplo, pytest --lf ), abreviatura de --last-failed (opciones útiles similares pueden ser --failed-first y --new-first , que puede funcionar bien con -x )
Dado que Pytest 3.10 existe --sw ( --stepwise ), que funciona a través de fallas conocidas de la misma manera que --lf y -x se pueden usar, que se pueden combinar con --stepwise-skip para controlar qué prueba es el enfoque actual
Si conoce los nombres de las pruebas que están fallando y/o en una ubicación específica, puede limitar las pruebas a una ubicación particular (por ejemplo, pytest tests/model ) o usar una palabra clave seleccionada (por ejemplo, pytest -k __handle )
Cuando solo se ejecuta un subconjunto de pruebas, se vuelve más práctico y útil usar la opción -v ( --verbose ); en lugar de mostrar a . (o F , E , x , etc.) Para cada resultado de la prueba, proporciona el nombre (con parámetros) de cada prueba que se ejecuta (por ejemplo, pytest -v -k __handle ). Esta opción también muestra más detalles en las pruebas y se puede administrar varias veces (por ejemplo, pytest -vv ).
Para obtener ayuda adicional con las opciones de Pytest, consulte pytest -h , o consulte la documentación completa de Pytest.
print El STDOUT (salida estándar) para Zulip-terminal se redirige a ./debug.log si la depuración está habilitada en tiempo de ejecución usando -d o --debug .
Esto significa que si desea verificar el valor de una variable, o tal vez indicar alcanzar un cierto punto en el código, simplemente puede usar print() , por ejemplo.
print ( f"Just about to do something with { variable } " ) y cuando se ejecuta con una opción de depuración, la cadena se imprimirá en ./debug.log .
Con un terminal con forma de bash, puede ejecutar algo como tail -f debug.log en otro terminal, para ver la salida de print a medida que sucede.
Si desea depurar Zulip-terminal mientras se está ejecutando, o en un estado específico, puede insertar
from pudb . remote import set_trace
set_trace () En la parte del código que desea depurar. Esto iniciará una conexión Telnet para usted. Puede encontrar la dirección IP y el puerto de la conexión Telnet en ./debug.log . Entonces simplemente corre
$ telnet 127.0.0.1 6899
En otro terminal, donde 127.0.0.1 es la dirección IP y 6899 es el puerto en el que encuentra ./debug.log .
Esto probablemente significa que ha instalado versiones normales y de desarrollo de Zulip-terminal.
Para asegurarse de ejecutar la versión de desarrollo:
Si se usa Pipenv, llame pipenv run zulip-term desde el directorio zulip-terminal clonado/descargado;
Si usa PIP (PIP3), asegúrese de haber activado el entorno virtual correcto (VENV); Dependiendo de cómo se configure su shell, el nombre de VenV puede aparecer en el símbolo del sistema. Tenga en cuenta que no incluir el -e en el comando pip3 también causará este problema.
