zulip terminal
Zulip Terminal 0.7.0
Changements récents | Configuration | Hot Keys | FAQ | Développement | Tutoriel
Zulip Terminal est le client de terminal officiel de Zulip, fournissant une interface utilisateur basée sur le texte (TUI).
Les objectifs spécifiques comprennent:
Apprenez à utiliser Zulip Terminal avec notre tutoriel.
Nous considérons que le client offre déjà une expérience de l'utilisateur quotidien modérément modérément stable.
L'accent actuel de développement est d'améliorer les aspects de l'utilisation quotidienne qui sont plus couramment utilisés - pour réduire la nécessité pour les utilisateurs de passer temporairement à un autre client pour une fonctionnalité particulière.
Les limitations actuelles que nous prévoyons de résoudre à long terme incluent le support pour:
Le client terminal a actuellement un certain nombre de différences intentionnelles avec le client Web Zulip:
Pour les requêtes sur la prise en charge des fonctionnalités manquantes, veuillez consulter les questions fréquemment posées (FAQ), nos problèmes ouverts ou discuter avec les utilisateurs et les développeurs en ligne sur le serveur communautaire Zulip!
Nous vous recommandons d'installer dans un environnement virtuel Python dédié (voir ci-dessous) ou d'utiliser une option automatisée telle que PIPX
STABLES STRABLE - Celles-ci sont disponibles sur PYPI comme le package zulip-terme
Pour installer, exécutez une commande comme: pip3 install zulip-term
Dernières versions (GIT) - La dernière version de développement peut être installée à partir de la branche main du référentiel GIT
Pour installer, exécutez une commande comme: pip3 install git+https://github.com/zulip/zulip-terminal.git@main
Nous fournissons également quelques exemples de dockerfiles pour construire des images docker dans docker /.
Avec le Python 3.6+ requis pour l'exécution, ce qui suit devrait fonctionner sur la plupart des systèmes:
python3 -m venv zt_venv (Crée un environnement virtuel nommé zt_venv dans le répertoire actuel)source zt_venv/bin/activate (active l'environnement virtuel; cela suppose une coque de type bash) Si vous ouvrez une fenêtre de terminal différente (ou connectez / redémarrez votre ordinateur), vous devrez à nouveau exécuter l'étape 2 de la liste ci-dessus avant d'exécuter zulip-term , car cela active cet environnement virtuel. Vous pouvez en savoir plus sur les environnements virtuels dans la documentation Venv de la bibliothèque Python 3.
Notez qu'il n'y a pas de système de mise à jour automatique, veuillez donc suivre les emplacements de mise à jour pertinents pour votre version d'installation:
Sorties stables
Avant la mise à niveau, nous vous recommandons de vérifier les modifications dans les versions récentes afin que vous soyez conscient des changements importants entre les versions.
Ceux-ci sont désormais annoncés dans l'annonce # Annonce> Terminal Relaying Topic sur le serveur communautaire Zulip (https://chat.zulip.org), qui est visible sans compte.
Si vous souhaitez recevoir des e-mails lorsque les mises à jour sont annoncées, vous êtes invités à vous inscrire à un compte sur ce serveur, ce qui vous permettra d'activer les notifications par e-mail pour le flux #Announce (article d'aide, paramètres de notifications sur Chat.zulip.org).
Vous pouvez également personnaliser votre paramètre GitHub Watch sur la page du projet pour inclure les versions.
PYPI fournit un flux de version RSS et divers autres services suivent ces informations.
Dernières versions (git)
Les versions installées à partir de la branche GIT main ne se mettront pas à jour automatiquement - le «dernier» fait référence à l'état au point d'installation.
Cela s'applique également aux autres installations source ou développement (par exemple, https://aur.archlinux.org/packages/python-zulip-term-git/).
Par conséquent, mettez à niveau votre package à l'aide de la commande ci-dessus, ou un pertinent pour votre système de package (par exemple, Arch).
Bien que la branche main soit destinée à rester stable, si la mise à niveau entre deux versions arbitraires «les dernières», sachez que les modifications ne sont pas résumées , bien que notre journal de validation soit très lisible.
Lors de l'exécution zulip-term en cours d'exécution, il recherche un fichier zuliprc , par défaut dans votre répertoire domestique, qui contient les détails pour se connecter à un serveur Zulip.
S'il ne trouve pas ce fichier, vous avez deux options:
zulip-term vous invitera à votre serveur, à un e-mail et à un mot de passe, et créera un fichier zuliprc pour vous à cet emplacement
Remarque: Si vous utilisez Google, GitHub ou une autre authentification externe pour accéder à votre organisation Zulip, vous n'aurez probablement pas de mot de passe et vous devez actuellement en créer un pour utiliser Zulip-terminal.
<Zulip server URL>/accounts/password/reset/ Pour créer un nouveau mot de passe pour votre compte (par exemple: https://chat.zulip.org/accouts/password/reset/). Chaque fois que vous exécutez zulip-term , vous pouvez spécifier le chemin d'accès à un autre fichier zuliprc à l'aide des options -c ou --config-file , par exemple. $ zulip-term -c /path/to/zuliprc
Un fichier .zuliprc correspondant à votre compte sur un serveur Zulip particulier peut être téléchargé via des applications Web ou de bureau connectées à ce serveur. Dans les versions récentes, cela peut être trouvé dans vos paramètres personnels dans la section Compte & Privacy , sous la clé API comme «Afficher / modifier votre clé API».
S'il s'agit de votre seul compte Zulip, vous souhaiterez peut-être déplacer et renommer ce fichier à l'emplacement du fichier par défaut ci-dessus, ou le renommer à quelque chose de plus mémorable que vous pouvez transmettre à l'option ---config-file . Ce fichier .zuliprc vous donne toutes les autorisations que vous avez en tant qu'utilisateur.
.zuliprc files similaires peuvent être téléchargés à partir de la section bots pour tous les robots que vous avez mis en place, mais avec des autorisations limitées en conséquence.
REMARQUE: Si votre serveur utilise des certificats auto-signés ou une connexion sans sécurité, vous devrez ajouter manuellement les options supplémentaires au fichier zuliprc - voir la documentation du module Zulip Python.
Nous vous suggérons d'exécuter zulip-term à l'aide de l'option -e ou --explore (en mode Explore) lorsque vous essayez le terminal zulip pour la première fois, où nous ne marquons pas intentionnellement les messages comme lus. Essayez de suivre notre tutoriel pour comprendre les choses.
Le fichier zuliprc contient deux sections:
[api] avec des informations nécessaires pour se connecter à votre serveur Zulip[zterm] avec une configuration spécifique à zulip-term Un fichier avec seule la première section peut être généré automatiquement dans certains cas par zulip-term , ou vous pouvez en télécharger un à partir de votre compte sur votre serveur (voir ci-dessus). Des parties de la deuxième section peuvent être ajoutées et ajustées par étapes lorsque vous souhaitez personnaliser le comportement du zulip-term .
L'exemple ci-dessous, avec le contenu de la section factice [api] , représente un fichier de configuration de travail avec toutes les valeurs [zterm] compatibles par défaut non composées et avec des notes d'accompagnement:
[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
Remarque: La plupart de ces paramètres de configuration peuvent être spécifiés sur la ligne de commande lorsque
zulip-termest démarré;zulip-term -houzulip-term --helpdonnera la liste complète des options.
Notez que les notifications ne sont pas actuellement prises en charge sur WSL; Voir # 767.
La commande suivante installe notify-send sur les systèmes basés sur Debian, des commandes similaires peuvent également être trouvées pour d'autres systèmes Linux.
sudo apt-get install libnotify-bin
Aucun package supplémentaire n'est requis pour activer les notifications dans OS X. Cependant, pour avoir un son de notification, définissez la variable suivante (en fonction de votre type de shell). La valeur sonore (ici ping) peut être l'un des fichiers .aiff trouvés sur /System/Library/Sounds ou ~/Library/Sounds .
Frapper
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.bash_profile
source ~/.bash_profile
Zsh
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.zshenv
source ~/.zshenv
Zulip Terminal permet aux utilisateurs de copier certains textes dans le presse-papiers via un module Python, Pyperclip . Ce module utilise divers packages système qui peuvent ou non venir avec le système d'exploitation. La fonction "Copier dans le presse-papiers" n'est actuellement disponible que pour la copie des e-mails Stream, à partir de la fenêtre contextuelle des informations Stream.
Sur Linux, ce module utilise les commandes xclip ou xsel , qui devraient déjà être livrées avec le système d'exploitation. Si aucune de ces commandes n'est installée sur votre système, alors installez une personne en utilisant:
sudo apt-get install xclip [Recommended]
OU
sudo apt-get install xsel
Aucun package supplémentaire n'est requis pour permettre la copie dans le presse-papiers.
Alors que Zulip Terminal est conçu pour fonctionner avec n'importe quel serveur Zulip, les principaux contributeurs sont présents sur le serveur communautaire Zulip à https://chat.zulip.org, avec la plupart des conversations dans le flux # zulip-terminal .
Vous êtes invités à afficher les conversations dans ce flux en utilisant le lien ci-dessus, ou inscrivez-vous à un compte et discutez avec nous - que vous soyez un utilisateur ou un développeur!
Nous visons à garder le Zulip communautaire, accueillant et productif, donc si vous participez, veuillez respecter nos normes communautaires.
Ce sont un sous-ensemble des normes communautaires liées ci-dessus, qui sont plus pertinentes pour les utilisateurs du terminal Zulip: ceux qui sont plus susceptibles d'être dans un environnement texte, limité dans les lignes / colonnes de caractères, et présents dans ce petit flux.
Préférer le texte dans les blocs de code, au lieu de captures d'écran
Zulip Terminal prend en charge le téléchargement des images, mais rien ne garantit que les utilisateurs pourront les visualiser.
Essayez Meta + M pour voir les exemples de formatage de contenu, y compris les blocs de code
Préfèrent les mentions silencieuses aux mentions régulières - ou éviter les mentions entièrement
Avec les sujets de Zulip, le destinataire prévu peut souvent être déjà clair. Les membres expérimentés seront présents si leur temps le permet - répondre aux messages à leur retour - et d'autres peuvent être en mesure d'aider avant cela.
(Économisez des mentions régulières pour ceux que vous ne vous attendez pas à être présents régulièrement)
Essayez Ctrl + F / B pour faire du vélo dans le contenu du message, après avoir tapé @_ pour spécifier une mention silencieuse
Préférez la citation de coupe et répondez au texte uniquement aux parties pertinentes des messages plus longs - ou évitez de citer entièrement
Les sujets de Zulip indiquent souvent que le message que vous répondez. Les messages longs peuvent être plus difficiles à lire avec des lignes et des colonnes limitées de texte, mais cela est aggravé s'il citant un long message entier avec du contenu supplémentaire.
Essayez > pour citer un message sélectionné, en supprimant le texte comme d'habitude lors de la composition d'un message
Préférez une réaction à emoji rapide pour montrer un accord au lieu de messages courts simples
Les réactions prennent moins de place, y compris dans le terminal zulip, en particulier lorsque plusieurs utilisateurs souhaitent répondre avec le même sentiment.
Essayez + pour faire basculer les pouces (+1) sur un message ou utiliser : pour rechercher d'autres réactions
Zulip Terminal est construit par la communauté Zulip impressionnante.
Pour en faire partie et contribuer au code, n'hésitez pas à travailler sur tout problème ou à proposer votre idée sur # Zulip-terminal.
Pour la structure et le style de la validation, veuillez consulter la section Style Commit ci-dessous.
Si vous êtes nouveau dans git (ou non!), Vous pouvez bénéficier du guide Zulip Git. Lors de la contribution, il est important de noter que nous utilisons un flux de travail orienté vers la rebase .
Un tutoriel simple est disponible pour implémenter l'indicateur typing . Suivez-le pour comprendre comment implémenter une nouvelle fonctionnalité pour Zulip-terminal.
Vous pouvez bien sûr parcourir la source sur GitHub et dans l'arborescence source que vous téléchargez, et vérifier l'aperçu du fichier source pour les idées de la façon dont les fichiers sont actuellement organisés.
Le terminal Zulip utilise Urwid pour rendre les composants de l'interface utilisateur dans le terminal. Urwid est une bibliothèque impressionnante à travers laquelle vous pouvez rendre une interface utilisateur terminale décente à l'aide de Python. Le tutoriel d'Urwid est un excellent point de départ pour de nouveaux contributeurs.
Tout d'abord, fourchez le référentiel zulip/zulip-terminal sur GitHub (voir comment), puis clonez votre référentiel fourchu localement, en remplaçant votre_username par votre nom d'utilisateur GitHub:
$ git clone --config pull.rebase [email protected]:YOUR_USERNAME/zulip-terminal.git
Cela devrait créer un nouveau répertoire pour le référentiel dans le répertoire actuel, alors entrez le répertoire du référentiel avec cd zulip-terminal et configurez et récupérez le référentiel distant en amont pour votre fourche clonée de la borne zulip:
$ git remote add -f upstream https://github.com/zulip/zulip-terminal.git
Pour des explications détaillées sur les commandes utilisées pour le clonage et la configuration en amont, reportez-vous à l'étape 1 de la section Get Zulip Code du guide GIT de Zulip.
Diverses options sont disponibles; Nous explorons les avantages de chacun et apprécierions les commentaires sur lesquels vous utilisez ou sentez le mieux.
Notez que les outils utilisés dans chaque cas sont généralement les mêmes, mais sont appelés de différentes manières.
Les commandes suivantes doivent être exécutées dans le répertoire du référentiel, créé par un processus similaire à celui de la section précédente.
$ pip3 install --user pipenv
--python 3.6 pour être plus spécifique) $ pipenv --three
$ pipenv install --dev
$ pipenv run pip3 install -e '.[dev]'
$ pipenv run gitlint install-hook
Créer et activer manuellement un environnement virtuel; Toute méthode doit fonctionner, comme celle utilisée dans l'installation simple ci-dessus
python3 -m venv zt_venv (Crée un Venv nommé zt_venv dans le répertoire actuel)source zt_venv/bin/activate (active le VENV; cela suppose une coque en forme de bash)Installer zulip-terme, avec les exigences de développement
$ pip3 install -e '.[dev]'
$ gitlint install-hook
Il s'agit de l'approche la plus récente et la plus simple, si vous avez make :
make (configure un environnement virtuel installé dans zt_venv dans le répertoire actuel)source zt_venv/bin/activate (active le VENV; cela suppose une coque en forme de bash)gitlint install-hook (Connectez le crochet Gitlint Commit-Message)Une fois que vous avez un environnement de développement configuré, vous pourriez trouver le suivant utile, selon votre type d'environnement:
| Tâche | Faire et pip | Picenv |
|---|---|---|
| Courir normalement | zulip-term | pipenv run zulip-term |
| Exécuter en mode débogage | zulip-term -d | pipenv run zulip-term -d |
| Courir avec le profilage | zulip-term --profile | pipenv run zulip-term --profile |
| Exécutez tous les liners | ./tools/lint-all | pipenv run ./tools/lint-all |
| Exécutez tous les tests | pytest | pipenv run pytest |
| Rapport de couverture de test de construction | pytest --cov-report html:cov_html --cov=./ | pipenv run pytest --cov-report html:cov_html --cov=./ |
Si l'utilisation de la marque avec PIP, Running make garantira que l'environnement de développement est à jour avec les dépendances spécifiées, utile après avoir récupéré de Git et Rebasing.
Choisissez votre éditeur de texte préféré ou votre environnement de développement!
La source comprend un fichier .editorconfig qui permet à de nombreux éditeurs de se configurer automatiquement pour produire des fichiers qui répondent aux exigences minimales du projet. Voir https://editorconfig.org pour la prise en charge de l'éditeur; Notez que certains peuvent nécessiter des plugins si vous souhaitez utiliser cette fonctionnalité.
Les liners et les tests automatisés (Pytest) sont automatiquement exécutés en CI (actions GitHub) lorsque vous soumettez une demande de traction (PR), ou poussez les modifications à une demande de traction existante.
Cependant, l'exécution de ces vérifications sur votre ordinateur peut accélérer votre développement en évitant la nécessité de pousser à plusieurs reprises votre code vers GitHub. Les commandes pour y parvenir sont répertoriées dans le tableau des tâches de développement ci-dessus (les liners individuels peuvent également être exécutés via des scripts dans tools/ ).
De plus, si vous utilisez un système basé sur make :
make lint et make test de chaque groupe de tâchesmake check de chèques Tous les chèques, ce qui est utile avant de pousser un PR (ou une mise à jour)tools/check-branch exécuteront make check sur chaque engagement dans votre succursaleRemarque: Il est très peu probable qu'une demande de traction soit fusionnée, jusqu'à ce que tous les lineurs et tests passent, y compris par engagement.
Correction de certaines erreurs de liaison nécessite une intervention manuelle, comme de mypy pour la vérification du type.
Pour des conseils sur les tests, veuillez consulter la section plus loin en ce qui concerne Pytest.
Cependant, d'autres erreurs de liaison peuvent être corrigées automatiquement, comme détaillé ci-dessous - cela peut gagner beaucoup de temps en ajustant manuellement votre code pour passer les liners!
Si vous avez du mal à comprendre pourquoi les liners ou Pytest échouent, veuillez pousser votre code vers une branche / PR et nous pouvons discuter des problèmes de PR ou sur Chat.zulip.org.
Si vous les mettez à jour, notez que vous n'avez pas besoin de mettre à jour le texte dans les deux endroits manuellement pour passer la liaison.
La source de la vérité est dans le code source, alors mettez simplement à jour le fichier Python et exécutez l'outil pertinent. Actuellement, nous avons:
tools/lint-hotkeys --fix pour régénérer les documents / hotkeys.md à partir de config / keys.pytools/lint-docstring --fix pour régénérer les documents / développeur-file-overview.md à partir de docstrings de fichiers(Ces outils sont également utilisés pour le processus de liaison, pour s'assurer que ces fichiers sont synchronisés)
Le projet utilise black et isort pour le style de code et le tri d'importation respectivement.
Ces outils peuvent être exécutés en tant que lineurs localement, mais peuvent également formater automatiquement votre code pour vous.
Si vous utilisez une configuration basée sur make , Running make fix s'exécutera à la fois (et quelques autres outils) et réformez l'état actuel de votre code - vous voudrez donc vous engager d'abord au cas où, alors --amend cela si vous êtes satisfait des modifications.
Vous pouvez également utiliser les outils individuellement sur un fichier ou un répertoire, par exemple. tests black zulipterminal ou isort tests/model/test_model.py
Lorsque vous travaillez localement, enquêtant sur les modifications à apporter, il est courant de faire une série de petits engagements pour stocker vos progrès. Souvent, cela peut inclure des engagements qui résolvent les problèmes de liaison ou de test dans les commit précédents. Ce sont des engagements de style développement - et presque tout le monde est susceptible d'écrire des engagements dans ce style dans une certaine mesure.
Les engagements de style de développement stockent les changements très bien pour vous en ce moment. Cependant, lorsque vous partagez votre code, les messages de validation sont un excellent endroit pour communiquer à la place aux autres ce que vous changez et pourquoi. Ranger la structure peut également faciliter et plus rapidement un lecteur de comprendre les changements et que vous respectez son temps. Un exemple est que les très grands engins peuvent prendre beaucoup de temps à examiner, par rapport à leur division. Un autre est que si vous corrigez les tests / libellés dans un engagement: qui commit (ou commet!) Est-ce que cela correcte, et s'il se trouve dans la même branche / PR, pourquoi l'engagement d'origine n'est-il pas simplement réparé à la place?
Par conséquent, lors de la création d'une demande de traction (PR), veuillez considérer que votre code est plus susceptible d'être fusionné, plus rapidement, s'il est plus facile de lire, de comprendre et de réviser - et une grande partie de cela est la façon dont vous structurez vos modifications en engagements et décrivez ces changements dans les messages de validation.
Pour être productif et faciliter la révision et la mise à jour de votre PRS, nous suivons une approche adoptée à Zulip et ailleurs, visant que PRS consiste en une série de validations cohérentes minimales :
Notez que le maintien de ces principes peut offrir d'autres avantages, avant, pendant et après avoir examiné un RP, notamment:
git bisect dans votre branche ou sur main Nous appliquons désormais un aspect limité de la nature cohérente des validations dans un RP dans un travail dans le cadre de notre intégration continue (IC), garantissons les commits des relations publiques isolées , qui exécutent essentiellement make check de chaque engagement dans votre branche. Vous pouvez le reproduire localement avant de pousser vers GitHub à l'aide tools/check-branch .
Bien que les PR petite ou preuve de concept soient initialement bien à pousser comme ils le sont, ils ne seront probablement examinés que sur les changements globaux. Généralement, si les engagements individuels semblent avoir un style de développement, les examinateurs sont susceptibles de donner des commentaires moins spécifiques, et des engagements cohérents minimaux doivent être demandés avant la fusion.
Commandes de restructuration - La majeure partie de la restructuration repose sur le rebasing interactif (par exemple, git rebase -i upstream/main ), mais envisagez de rechercher des actions spécifiques en ligne, ainsi que de la recherche ou de la demande dans l'aide #Git ou #learning sur Chat.zulip.org.
Auto-revue - Une autre approche utile consiste à revoir vos propres engagements à la fois localement (voir Zulip Suggestions) et après avoir poussé à GitHub. Cela vous permet d'inspecter et de réparer tout ce qui semble hors de propos, que quelqu'un est susceptible de prendre dans son avis, aidant vos soumissions plus polies, ainsi que vous indiquant à nouveau que vous respectez le temps des critiques.
Nous visons à suivre un style de validation standard pour garder le git log cohérent et facile à lire.
Tout comme travailler avec le code, nous vous suggérons de vous référer aux commits récents dans le journal GIT, pour des exemples du style que nous utilisons activement.
Notre style global pour les messages de validation suit largement les directives générales données pour les messages de validation Zulip, nous recommandons donc d'abord la lecture.
Nos titres de validation (résumés) ont de légères variations du style Zulip général, avec chacun:
/Tests updated ou Tests added dans le texte de la validation)refactor: , bugfix: et requirements: (voir ci-dessous)Certains exemple commettent des titres: (idéalement plus descriptif dans la pratique!)
file3/file1/file2: Improve behavior of something.file1.txt , file2.py et file3.mdrefactor: file1/file2: Extract some common function.file1.py et file2.pybugfix: file1: Avoid some noticeable bug.file1.pytests: file1: Improve test for something.file1 , probablement dans test_file1.pyrequirements: Upgrade some-dependency from ==9.2 to ==9.3. Pour aider à satisfaire certaines de ces règles, vous pouvez utiliser GitLint , comme décrit dans la section suivante.
Cependant , veuillez vérifier vos engagements manuellement par rapport à ces règles de style, car Gitlint ne peut pas tout vérifier - y compris la langue ou la grammaire!
L'outil gitlint est installé par défaut dans l'environnement de développement et peut vous assurer que vos engagements respectent la norme attendue.
L'outil peut vérifier les engagements spécifiques manuellement, par exemple. gitlint pour le dernier commit, ou gitlint --commits main.. pour les engins menant de main . Cependant, nous vous recommandons fortement d'exécuter gitlint install-hook pour installer le crochet gitlint Commit-Message (ou pipenv run gitlint install-hook avec PiPenv Setups).
Si le crochet est installé comme décrit ci-dessus, après avoir terminé le texte pour un engagement, il sera vérifié par Gitlint contre le style que nous avons mis en place et offrira des conseils s'il y a des problèmes qu'il remarque. Si Gitlint en trouve, il vous demandera si vous souhaitez vous engager avec le message tel qu'il est ( y pour «oui»), arrêtez le processus de validation ( n pour «non») ou modifiez le message de validation ( e pour «modifier»).
Bien que le contenu dépend toujours de vos compétences en écriture, cela garantit une structure de formatage plus cohérente entre les commits, y compris par différents auteurs.
Les tests de zulip-terminal sont écrits à l'aide de PyTest. Vous pouvez lire les tests dans le dossier /tests pour en savoir plus sur la rédaction de tests pour une nouvelle classe / fonction. Si vous êtes nouveau dans Pytest, la lecture de sa documentation est définitivement recommandée.
Nous avons actuellement des milliers de tests qui sont vérifiés lors de l'exécution pytest . Bien qu'il dépend de la capacité de votre système, cela devrait généralement prendre moins d'une minute pour fonctionner. Cependant, lors du débogage, vous pouvez toujours souhaiter limiter la portée de vos tests, pour améliorer le délai d'exécution:
Si de nombreux tests échouent de manière très verbale, vous pouvez essayer l'option -x (par exemple pytest -x ) pour arrêter les tests après la première défaillance; En raison de la paramétrisation des tests et des luminaires de test, de nombreuses erreurs / échecs apparentes peuvent être résolus avec une seule correction! (essayez par exemple pytest --maxfail 3 pour une version moins stricte de ceci)
Pour éviter d'exécuter tous les tests réussis à chaque fois, ainsi que les échecs, vous pouvez exécuter --lf (par exemple pytest --lf ), abréviation de --last-failed (des options utiles similaires peuvent être --failed-first et --new-first , qui peuvent bien fonctionner avec -x )
Puisque pytest 3.10 il y a --sw ( --stepwise ), qui fonctionne à travers des échecs connus de la même manière que --lf et -x peuvent être utilisés, qui peuvent être combinés avec --stepwise-skip pour contrôler quel test est le foyer actuel
Si vous connaissez les noms des tests qui échouent et / ou dans un emplacement spécifique, vous pouvez limiter les tests à un emplacement pytest tests/model ( pytest -k __handle exemple.
Lorsque seul un sous-ensemble de tests s'exécute, il devient plus pratique et utile d'utiliser l'option -v ( --verbose ); Au lieu de montrer un . (ou F , E , x , etc.) Pour chaque résultat de test, il donne le nom (avec des paramètres) de chaque test exécuté (par exemple, pytest -v -k __handle ). Cette option affiche également plus de détails dans les tests et peut être donnée plusieurs fois (par exemple, pytest -vv ).
Pour une aide supplémentaire avec les options de Pytest, consultez pytest -h ou consultez la documentation complète de Pytest.
print Le stdout (sortie standard) pour Zulip-terminal est redirigé vers ./debug.log si le débogage est activé au moment de l'exécution à l'aide -d ou --debug .
Cela signifie que si vous souhaitez vérifier la valeur d'une variable, ou peut-être indiquer à un certain point dans le code, vous pouvez simplement utiliser print() , par exemple.
print ( f"Just about to do something with { variable } " ) Et lors de l'exécution avec une option de débogage, la chaîne sera imprimée sur ./debug.log .
Avec un terminal de type bash, vous pouvez exécuter quelque chose comme tail -f debug.log dans un autre terminal, pour voir la sortie de print telle qu'elle se produit.
Si vous souhaitez déboguer zulip-terminal pendant qu'il est en cours d'exécution, ou dans un état spécifique, vous pouvez insérer
from pudb . remote import set_trace
set_trace () Dans la partie du code que vous souhaitez déboguer. Cela lancera une connexion Telnet pour vous. Vous pouvez trouver l'adresse IP et le port de la connexion Telnet dans ./debug.log . Ensuite, courez simplement
$ telnet 127.0.0.1 6899
Dans un autre terminal, où 127.0.0.1 est l'adresse IP et 6899 est le port que vous trouvez dans ./debug.log .
Cela signifie probablement que vous avez installé à la fois des versions normales et de développement de zulip-terminal.
Pour vous assurer d'exécuter la version de développement:
Si vous utilisez PIPENV, appelez pipenv run zulip-term à partir du répertoire zulip-terminal cloné / téléchargé;
Si vous utilisez PIP (PIP3), assurez-vous d'avoir activé l'environnement virtuel correct (VENV); Selon la façon dont votre shell est configuré, le nom du VENV peut apparaître dans l'invite de commande. Notez que le fait de ne pas inclure le -e dans la commande PIP3 entraînera également ce problème.
