zulip terminal
Zulip Terminal 0.7.0
Jüngste Änderungen | Konfiguration | Heiße Schlüssel | FAQs | Entwicklung | Tutorial
Zulip Terminal ist der offizielle Terminal-Client für Zulip und bietet eine textbasierte Benutzeroberfläche (TUI).
Spezifische Ziele sind:
Erfahren Sie, wie Sie Zulip Terminal mit unserem Tutorial verwenden.
Wir betrachten den Kunden als eine ziemlich stabile, mäßig fehlerhafte Erfahrung im Alltag.
Der aktuelle Entwicklungsfokus liegt auf der Verbesserung der alltäglichen Verwendung, die häufiger verwendet werden, um die Notwendigkeit zu verringern, dass Benutzer vorübergehend zu einem anderen Kunden für eine bestimmte Funktion wechseln.
Aktuelle Einschränkungen, die wir erwarten, nur langfristig zu lösen, beinhalten die Unterstützung für:
Der Terminal -Client hat derzeit eine Reihe absichtlicher Unterschiede im Zulip -Web -Client:
Für Fragen zum fehlenden Feature -Support sehen Sie sich bitte die häufig gestellten Fragen (FAQs), unsere offenen Probleme an oder chatten Sie online mit Benutzern und Entwicklern auf dem Zulip Community Server!
Wir empfehlen, in einer dedizierten virtuellen Python -Umgebung (siehe unten) zu installieren oder eine automatisierte Option wie PIPX zu verwenden
Stabile Veröffentlichungen - diese sind auf PYPI als Paket Zulip -Term erhältlich
Führen Sie einen Befehl aus wie: pip3 install zulip-term
Neueste (GIT-) Versionen - Die neueste Entwicklungsversion kann aus der main der GIT -Repository installiert werden
Führen Sie einen Befehl wie: pip3 install git+https://github.com/zulip/zulip-terminal.git@main
Wir stellen auch einige Beispiele für Dockerfiles zur Verfügung, um Docker -Bilder in Docker/zu erstellen.
Mit dem für das Laufen erforderlichen Python 3.6+ sollte Folgendes auf den meisten Systemen funktionieren:
python3 -m venv zt_venv (erstellt eine virtuelle Umgebung mit dem Namen zt_venv im aktuellen Verzeichnis)source zt_venv/bin/activate (aktiviert die virtuelle Umgebung; Dies setzt eine bash-ähnliche Hülle an) Wenn Sie ein anderes Terminalfenster öffnen (oder Ihren Computer abmelden/neu starten), müssen Sie Schritt 2 der obigen Liste erneut ausführen, bevor Sie zulip-term ausführen, da dies diese virtuelle Umgebung aktiviert. Sie können mehr über virtuelle Umgebungen in der Python 3 -Bibliotheksvenv -Dokumentation erfahren.
Beachten Sie, dass es kein automatisches Update-System gibt. Verfolgen Sie daher die für Ihre Installationsversion relevanten Aktualisierungsorte:
Stabile Veröffentlichungen
Vor dem Upgrade empfehlen wir Ihnen, die Änderungen in den letzten Veröffentlichungen zu überprüfen, damit Sie wichtige Änderungen zwischen den Veröffentlichungen kennen.
Diese werden nun im # Ankündigung> Terminal -Releases -Thema auf dem Zulip Community Server (https://chat.zulip.org) bekannt gegeben, das ohne Konto sichtbar ist.
Wenn Sie E -Mails erhalten möchten, wenn Updates angekündigt werden, können Sie sich für ein Konto auf diesem Server anmelden, mit dem Sie E -Mail -Benachrichtigungen für den #Announce -Stream aktivieren können (Help -Artikel, Benachrichtigungseinstellungen auf chat.tzulip.org).
Sie können Ihre GitHub -Uhreneinstellung auch auf der Projektseite an die Veröffentlichungen anpassen.
PYPI bietet einen RSS -Release -Feed, und verschiedene andere Dienste verfolgen diese Informationen.
Neueste (Git) Versionen
Die von der main -Filiale installierten Versionen werden ebenfalls nicht automatisch aktualisiert - der "neueste" bezieht sich auf den Status am Installationspunkt.
Dies gilt auch für andere Installationen für andere Quellen oder Entwicklungen (z. B. https://aur.archlinux.org/packages/python-zu-zulip-mate-git/).
Aktualisieren Sie daher Ihr Paket mit dem obigen Befehl oder einem für Ihr Paketsystem (z. B. Arch).
Während der main stabil bleiben soll, beachten Sie bitte, dass Änderungen nicht zusammengefasst werden , obwohl unser Commit -Protokoll sehr lesbar sein sollte.
Nach dem ersten Ausführen zulip-term sucht es standardmäßig nach einer zuliprc Datei in Ihrem Home-Verzeichnis, die die Details enthält, um sich bei einem Zulip-Server anzumelden.
Wenn diese Datei nicht gefunden wird, haben Sie zwei Optionen:
zulip-term fordert Sie für Ihren Server, Ihre E-Mail und Ihr Passwort auf und erstellt eine zuliprc Datei für Sie an diesem Ort
Hinweis: Wenn Sie Google, Github oder eine andere externe Authentifizierung verwenden, um auf Ihre Zulip-Organisation zuzugreifen, haben Sie wahrscheinlich keine Kennwortssatz und müssen derzeit eine erstellen, um Zulip-terminal zu verwenden.
<Zulip server URL>/accounts/password/reset/ Um ein neues Passwort für Ihr Konto zu erstellen (z. B. https://chat.tzulip.org/Accounts/password/reset/). Jedes Mal, wenn Sie zulip-term ausführen, können Sie den Pfad zu einer alternativen zuliprc Datei mit den Optionen für -c oder --config-file angeben, z. $ zulip-term -c /path/to/zuliprc
Eine .zuliprc -Datei, die Ihrem Konto auf einem bestimmten Zulip -Server entspricht, kann über Web- oder Desktop -Anwendungen heruntergeladen werden, die mit diesem Server verbunden sind. In jüngsten Versionen finden Sie dies in Ihren persönlichen Einstellungen im Abschnitt Konto und Datenschutz unter API -Schlüssel als "Zeigen/Ändern Ihres API -Schlüssels".
Wenn dies Ihr einziges Zulip-Konto ist, möchten Sie diese Datei möglicherweise über den obigen Standarddateispeicherort verschieben und umbenennen oder in etwas Einprägsamenderes umbenennen, das Sie an die Option ---config-file Option übergeben können. Diese .zuliprc -Datei gibt Ihnen alle Berechtigungen, die Sie als Benutzer haben.
Ähnliche .zuliprc files können für alle Bots, die Sie eingerichtet haben, aus dem Abschnitt Bots heruntergeladen werden, jedoch mit entsprechend begrenzten Berechtigungen.
Hinweis: Wenn Ihr Server selbstsignierte Zertifikate oder eine unsichere Verbindung verwendet, müssen Sie der zuliprc -Datei zusätzliche Optionen hinzufügen - siehe Dokumentation für das Zulip -Python -Modul.
Wir empfehlen, zulip-term mit der Option -e oder --explore (im Explore -Modus) auszuführen, wenn Sie zum ersten Mal das Zulip -Terminal versuchen, wo wir absichtlich keine Nachrichten wie gelesen markieren. Versuchen Sie, unser Tutorial mitzuteilen, um die Dinge zu finden.
Die zuliprc -Datei enthält zwei Abschnitte:
[api] mit Informationen, die erforderlich sind, um eine Verbindung zu Ihrem Zulip -Server herzustellen[zterm] -Ateabschnitt mit spezifischer Konfigurationspezifikation für zulip-term Eine Datei mit nur dem ersten Abschnitt kann in einigen Fällen von zulip-term automatisch generiert werden, oder Sie können eine von Ihrem Konto auf Ihrem Server herunterladen (siehe oben). Teile des zweiten Abschnitts können in Phasen hinzugefügt und angepasst werden, wenn Sie das Verhalten von zulip-term anpassen möchten.
Das folgende Beispiel mit Dummy [api] -Abschnittinhalt stellt eine funktionierende Konfigurationsdatei mit allen Standard -kompatiblen [zterm] -Werten, die sich nicht und mit begleitenden Notizen beziehen:
[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
Hinweis: Die meisten dieser Konfigurationseinstellungen können in der Befehlszeile angegeben werden, wenn
zulip-termgestartet wird.zulip-term -hoderzulip-term --helpgibt die vollständige Liste der Optionen.
Beachten Sie, dass Benachrichtigungen derzeit nicht auf WSL unterstützt werden. Siehe #767.
Der folgende Befehl installiert notify-send auf Debian-basierten Systemen. Ähnliche Befehle finden Sie auch für andere Linux-Systeme.
sudo apt-get install libnotify-bin
Es ist kein zusätzliches Paket erforderlich, um Benachrichtigungen in OS X zu aktivieren. Setzen Sie jedoch die folgende Variable (basierend auf Ihrem Shelltyp). Der Schallwert (hier Ping) kann eine der .aiff -Dateien sein, die unter /System/Library/Sounds oder ~/Library/Sounds gefunden wurden.
Verprügeln
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.bash_profile
source ~/.bash_profile
ZSH
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.zshenv
source ~/.zshenv
Mit Zulip Terminal können Benutzer bestimmte Texte über ein Python -Modul, Pyperclip , in die Zwischenablage kopieren. Dieses Modul verwendet verschiedene Systempakete, die möglicherweise mit dem Betriebssystem geliefert werden. Die Funktion "Kopieren in die Zwischenablage" ist derzeit nur zum Kopieren von Stream -E -Mails aus dem Stream -Informationen zum Popup verfügbar.
Unter Linux verwendet dieses Modul xclip oder xsel -Befehle, die bereits mit dem Betriebssystem geliefert werden sollten. Wenn keines dieser Befehle auf Ihrem System installiert ist, installieren Sie eine mit:
sudo apt-get install xclip [Recommended]
ODER
sudo apt-get install xsel
Es ist kein zusätzliches Paket erforderlich, um das Kopieren in Zwischenablage zu ermöglichen.
Während Zulip Terminal so konzipiert ist, dass sie mit jedem Zulip-Server arbeiten, sind die Hauptversorgungsmitglieder auf dem Zulip Community-Server unter https://chat.tzulip.org vorhanden, wobei die meisten Gespräche im #Zulip-terminalen Stream unterhalten werden.
Sie sind herzlich eingeladen, Gespräche in diesem Stream mit dem obigen Link anzuzeigen oder sich für ein Konto anzumelden und mit uns zu chatten - egal ob Sie Benutzer oder Entwickler sind!
Wir wollen die Zulip Community freundlich, einladend und produktiv halten. Wenn Sie also teilnehmen, respektieren Sie bitte unsere Community -Normen.
Dies sind eine Untergruppe der oben verknüpften Community -Normen , die für Benutzer von Zulip Terminal relevanter sind: diejenigen, die sich häufiger in einer Textumgebung befinden, in den Zeichenzeilen/-spalten begrenzt und in diesem einen kleineren Strom vorhanden sind.
Bevorzugen Sie Text in Codeblöcken anstelle von Screenshots
Zulip Terminal unterstützt das Herunterladen von Bildern, aber es gibt keine Garantie dafür, dass Benutzer sie anzeigen können.
Versuchen Sie Meta + M , um Beispielinhaltsformatierung, einschließlich Codeblöcke, anzuzeigen
Bevorzugen Sie stille Erwähnungen gegenüber regelmäßigen Erwähnungen - oder vermeiden Sie vollständig Erwähnungen
Bei Zulips Themen kann der beabsichtigte Empfänger oft bereits klar sein. Erfahrene Mitglieder werden als Zeitgenehmigungen anwesend sein - auf Nachrichten zu reagieren, wenn sie zurückkehren - und andere können vorher möglicherweise helfen.
(Sparen Sie regelmäßige Erwähnungen für diejenigen, von denen Sie nicht erwarten, dass sie regelmäßig anwesend sind.)
Versuchen Sie es mit Strg + F / B , um die automatische Vervollständigung im Nachrichteninhalt nach dem Eingeben @_ durchzuführen, um eine stille Erwähnung anzugeben
Bevorzugen
Zulips Themen machen oft klar, auf welche Nachricht Sie antworten. Lange Nachrichten können mit begrenzten Zeilen und Textspalten schwieriger zu lesen sein. Dies wird jedoch verschlechtert, wenn eine gesamte lange Nachricht mit zusätzlichen Inhalten angegeben wird.
Versuchen Sie > eine ausgewählte Nachricht zu zitieren und Text beim Komponieren einer Nachricht als normal zu löschen
Bevorzugen Sie eine schnelle Emoji -Reaktion, um Vereinbarung anstelle einfacher Kurznachrichten zu zeigen
Reaktionen nehmen weniger Platz ein, einschließlich im Zulip -Terminal, insbesondere wenn mehrere Benutzer mit demselben Gefühl antworten möchten.
Versuchen Sie + , um Daumen nach oben (+1) in eine Nachricht zu wechseln, oder verwenden Sie : nach anderen Reaktionen suchen
Zulip Terminal wird von der Awesome Zulip Community gebaut.
Um ein Teil davon zu sein und zum Code beizutragen, können Sie sich gerne an einem Problem arbeiten oder Ihre Idee auf #Zulip-terminal vorschlagen.
Für die Festungsstruktur und -Stil überprüfen Sie bitte den Abschnitt "Commit Style" unten.
Wenn Sie neu in git sind (oder nicht!), Profitieren Sie möglicherweise vom Zulip Git -Leitfaden. Beim Beitrag ist zu beachten, dass wir einen rebase-orientierten Workflow verwenden.
Ein einfaches Tutorial ist zur Implementierung des typing verfügbar. Befolgen Sie es, um zu verstehen, wie Sie eine neue Funktion für Zulip-terminal implementieren können.
Natürlich können Sie die Quelle auf Github und im Quellbaum, den Sie herunterladen, durchsuchen und die Übersicht über die Quelldatei überprüfen, um Ideen zu erhalten, wie Dateien derzeit angeordnet sind.
Zulip Terminal verwendet Urwid, um die UI -Komponenten im Terminal zu rendern. Urwid ist eine großartige Bibliothek, durch die Sie eine anständige Terminal -Benutzeroberfläche mit Python machen können. Urwids Tutorial ist ein großartiger Ort, um neue Mitwirkende zu beginnen.
Geben Sie zuerst das zulip/zulip-terminal Repository auf GitHub (siehe wie) und dann Ihr Forked Repository lokal klonen, wobei Sie Ihren_usernamen durch Ihren Github-Benutzernamen ersetzen:
$ git clone --config pull.rebase [email protected]:YOUR_USERNAME/zulip-terminal.git
Dies sollte ein neues Verzeichnis für das Repository im aktuellen Verzeichnis erstellen. Geben Sie daher das Repository-Verzeichnis mit cd zulip-terminal ein und konfigurieren und holen Sie das vorgelagerte Remote-Repository für Ihre geklonte Gabel von Zulip Terminal:
$ git remote add -f upstream https://github.com/zulip/zulip-terminal.git
Eine ausführliche Erläuterung der Befehle zum Klonen und Einrichten stromaufwärts finden Sie in Schritt 1 des Abschnitts GET Zulip -Code des Git -Handbuchs von Zulip.
Es stehen verschiedene Optionen zur Verfügung. Wir untersuchen die Vorteile der einzelnen und würden uns ein Feedback freuen, für das Sie am besten funktionieren.
Beachten Sie, dass die jeweils verwendeten Tools normalerweise gleich sind, aber auf unterschiedliche Weise aufgerufen werden.
Die folgenden Befehle sollten im Repository -Verzeichnis ausgeführt werden, das durch einen Prozess erstellt wurde, der dem im vorherigen Abschnitt ähnelt.
$ pip3 install --user pipenv
--python 3.6 , um spezifischer zu sein) $ pipenv --three
$ pipenv install --dev
$ pipenv run pip3 install -e '.[dev]'
$ pipenv run gitlint install-hook
Manuell eine virtuelle Umgebung erstellen und aktivieren; Jede Methode sollte funktionieren, wie die in der obigen einfachen Installation verwendet
python3 -m venv zt_venv (erstellt im aktuellen Verzeichnis ein Gebiet namens zt_venv )source zt_venv/bin/activate (aktiviert das Gebiet; Dies setzt eine bash-ähnliche Hülle an)Installieren Sie Zulip-Term mit den Entwicklungsanforderungen
$ pip3 install -e '.[dev]'
$ gitlint install-hook
Dies ist der neueste und einfachste Ansatz, wenn Sie make haben:
make (richten Sie eine installierte virtuelle Umgebung in zt_venv im aktuellen Verzeichnis ein)source zt_venv/bin/activate (aktiviert das Gebiet; Dies setzt eine bash-ähnliche Hülle an)gitlint install-hook (Verbinden Sie den Gitlint Commit-Message Hook)Sobald Sie eine Entwicklungsumgebung eingerichtet haben, können Sie je nach Art von Umgebung das folgende nützliche finden:
| Aufgabe | Make & pip | POBENV |
|---|---|---|
| Normal laufen | zulip-term | pipenv run zulip-term |
| Im Debug -Modus ausführen | zulip-term -d | pipenv run zulip-term -d |
| Mit Profilerstellung laufen | zulip-term --profile | pipenv run zulip-term --profile |
| Führen Sie alle Linter aus | ./tools/lint-all | pipenv run ./tools/lint-all |
| Führen Sie alle Tests aus | pytest | pipenv run pytest |
| Erstellen Sie den Testabdeckungsbericht | pytest --cov-report html:cov_html --cov=./ | pipenv run pytest --cov-report html:cov_html --cov=./ |
Wenn Sie Make mit PIP verwenden, stellen make sicher, dass die Entwicklungsumgebung mit den angegebenen Abhängigkeiten auf dem neuesten Stand ist, was nach dem Abholen von Git und Wiedergeburt nützlich ist.
Wählen Sie Ihren bevorzugten Texteditor oder Ihre Entwicklungsumgebung aus!
Die Quelle enthält eine .editorconfig -Datei, mit der viele Redakteure sich automatisch so konfigurieren können, dass Dateien erstellt werden, die den Mindestanforderungen für das Projekt entsprechen. Siehe https://editorconfig.org für den Herausgeber -Support; Beachten Sie, dass einige möglicherweise Plugins benötigen, wenn Sie diese Funktion verwenden möchten.
Die Linter und automatisierten Tests (PyTest) werden automatisch in CI (Github -Aktionen) ausgeführt, wenn Sie eine Pull -Anfrage (PR) einreichen, oder Änderungen an eine vorhandene Pull -Anfrage übertragen.
Durch das Ausführen dieser Überprüfungen auf Ihrem Computer können Sie jedoch Ihre Entwicklung beschleunigen, indem Sie vermeiden, dass Sie Ihren Code wiederholt auf GitHub drücken. Befehle, um dies zu erreichen, werden in der obigen Tabelle der Entwicklungsaufgaben aufgeführt (einzelne Linter können auch über Skripte in tools/ ) ausgeführt werden.
Außerdem, wenn Sie ein make -basiertes System verwenden:
make lint und make test .make check alle Schecks aus.tools/check-branch werden make checkHinweis: Es ist höchst unwahrscheinlich, dass eine Pull-Anfrage zusammengeführt wird, bis alle Linter und Tests bestehen, einschließlich pro Commit.
Durch die Korrektur einiger Stining-Fehler sind manuelle Eingriffe erforderlich, z mypy
Für Tipps zum Testen überprüfen Sie bitte den Abschnitt weiter unten in Bezug auf PyTest.
Andere Lingerfehler können jedoch automatisch behoben werden, wie unten beschrieben. Dies kann viel Zeit sparen, um Ihren Code manuell anzupassen, um die Linter zu übergeben!
Wenn Sie Probleme haben, zu verstehen, warum die Linter oder PyTest fehlschlagen, schieben Sie Ihren Code bitte in einen Zweig/PR und wir können die Probleme im PR oder auf Chat.zulip.org besprechen.
Wenn Sie diese aktualisieren, beachten Sie, dass Sie den Text nicht manuell an beiden Stellen aktualisieren müssen, um die Linie zu übergeben.
Die Quelle der Wahrheit befindet sich im Quellcode. Aktualisieren Sie daher einfach die Python -Datei und führen Sie das entsprechende Tool aus. Derzeit haben wir:
tools/lint-hotkeys --fix um docs/hotkeys.md von config/keys.py zu regenerierentools/lint-docstring --fix zum Regenerieren von DOCs/Developer-File-Overview.md von Dateidocstrings(Diese Tools werden auch für den Liningprozess verwendet, um sicherzustellen, dass diese Dateien synchronisiert sind)
Das Projekt verwendet black und isort für den Code-Stil und die Importsortierung.
Diese Tools können als Linter lokal ausgeführt werden, können jedoch auch Ihren Code automatisch für Sie formatieren.
Wenn Sie ein make -basiertes Setup verwenden, wird das Running make fix (und einige andere Tools) ausgeführt und den aktuellen Stand Ihres Code neu --amend . Sie möchten also zuerst für den Fall festlegen, dass Sie diese Verpflichtung mit den Änderungen zufrieden geben.
Sie können die Tools auch einzeln in einer Datei oder einem Verzeichnis verwenden, z. black zulipterminal oder isort tests/model/test_model.py
Während Sie vor Ort arbeiten, um Änderungen vorzunehmen, ist es üblich, eine Reihe kleiner Commits zu machen, um Ihre Fortschritte zu speichern. Dies kann häufig Commits umfassen, die Lining- oder Testprobleme in den vorherigen Ausschüssen beheben. Dies sind Commits im Entwicklungsstil - und fast jeder wird wahrscheinlich bis zu einem gewissen Grad Commits in diesem Stil schreiben.
Der Entwicklungsstil-Commits speichern die Änderungen für Sie im Moment in Ordnung. Wenn Sie jedoch Ihren Code teilen, sind die Bestimmungsnachrichten ein großartiger Ort, an dem Sie stattdessen anderen mitgeteilt werden können, was Sie sich ändern und warum. Das Aufräumen der Struktur kann es auch für einen Leser einfacher und schneller machen, Änderungen zu verstehen, und Sie respektieren seine Zeit. Ein Beispiel ist, dass sehr große einzelne Commits viel Zeit für die Überprüfung in Anspruch nehmen können, verglichen mit der Aufteilung. Ein weiterer Fall ist, wenn Sie die Tests/das Linken in einem Commit festlegen: Welches Commit (oder verpflichtet sich!) Und wenn es sich in derselben Niederlassung/PR befindet, warum ist das ursprüngliche Commit nicht stattdessen nur behoben?
Wenn Sie daher eine Pull -Anfrage (PR) erstellen, sollten Sie daher in Betracht ziehen, dass Ihr Code eher zusammengeführt wird, wenn es einfacher ist, Ihre Änderungen in Commits zu lesen, zu verstehen und zu überprüfen - und ein großer Teil davon ist so, wie Sie Ihre Änderungen in Commits strukturieren, und diese Änderungen in den Bekanntheitsmeldungen zu beschreiben.
Um produktiv zu sein und es Ihnen leichter zu machen, dass Ihre PRs überprüft und aktualisiert werden, folgen wir einem Ansatz, der bei Zulip und anderswo verfolgt wird und auf eine Reihe von minimalen kohärenten Commits strebt:
Beachten Sie, dass die Einhaltung dieser Prinzipien andere Vorteile sowohl vor, während als auch nach der Überprüfung einer PR geben kann, einschließlich:
git bisect in Ihrem Zweig oder am main Wir erzwingen nun einen begrenzten Aspekt der kohärenten Natur von Commits in einem PR in einem Job als Teil unserer kontinuierlichen Integration (CI) und sorgen für isolierte PR -Commits , die im Wesentlichen make check jedes Commits in Ihrer Niederlassung durchführen. Sie können dies lokal replizieren, bevor Sie mit tools/check-branch in GitHub drücken.
Während kleine oder Proof-of-Concept-PRs anfangs in Ordnung sind, werden sie wahrscheinlich nur auf der Grundlage der Gesamtänderungen überprüft. Wenn einzelne Commits so aussehen, als hätten sie einen Entwicklungsstil, geben die Rezensenten wahrscheinlich weniger spezifisches Feedback, und minimale kohärente Commits werden mit Sicherheit vor dem Zusammenführen angefordert.
Umstrukturierungsbefehle - Die meiste Umstrukturierung stützt sich auf das interaktive Wiedergeburt (z. B. git rebase -i upstream/main ), aber in Betracht ziehen, online nach bestimmten Aktionen zu suchen sowie in #Git Hilfe oder #Learning auf chat.tzulip.org zu suchen oder zu fragen.
Self Review - Ein weiterer nützlicher Ansatz besteht darin, Ihre eigenen Commits sowohl lokal (siehe Zulip -Vorschläge) und nach dem Drücken nach GitHub zu überprüfen. Auf diese Weise können Sie alles inspizieren und beheben, was fehl am Platz aussieht, was wahrscheinlich jemand in seiner Überprüfung aufgreift, wodurch Ihre Einsendungen polierter aussehen und erneut darauf hinweisen, dass Sie die Zeit der Rezensenten respektieren.
Wir wollen einen Standard -Commit -Stil befolgen, um das git log konsequent und leicht zu lesen zu halten.
Ähnlich wie bei der Arbeit mit Code empfehlen wir, dass Sie sich auf die aktuellen Commits im Git -Protokoll beziehen, um Beispiele für den Stil, den wir aktiv verwenden, aktiv.
Unser Gesamtstil für die Bekämpfung von Nachrichten folgt im Großen und Ganzen den allgemeinen Richtlinien für Zulip Commit -Nachrichten. Wir empfehlen daher, diese zuerst zu lesen.
Unsere Commit -Titel (Zusammenfassungen) haben mit jedem:
/Tests updated oder Tests added ).refactor: bugfix: und requirements: (siehe unten)Einige Beispiele begehen Titel: (idealerweise beschreibender in der Praxis!)
file3/file1/file2: Improve behavior of something.file1.txt , file2.py und file3.mdrefactor: file1/file2: Extract some common function.file1.py und file2.py umfasstbugfix: file1: Avoid some noticeable bug.file1.py zu behebentests: file1: Improve test for something.file1 , wahrscheinlich in test_file1.pyrequirements: Upgrade some-dependency from ==9.2 to ==9.3. Um einige dieser Regeln zu erfüllen, können Sie GitLint verwenden, wie im folgenden Abschnitt beschrieben.
Bitte überprüfen Sie jedoch Ihre Commits manuell im Vergleich zu diesen Stilregeln, da Gitlint nicht alles überprüfen kann - einschließlich Sprache oder Grammatik!
Das gitlint -Tool ist standardmäßig in der Entwicklungsumgebung installiert und kann dazu beitragen, dass Ihre Commits den erwarteten Standard entsprechen.
Das Tool kann bestimmte Commits manuell überprüfen, z. gitlint für das neueste Commit oder gitlint --commits main.. für Commits, die von main führen. Wir empfehlen jedoch dringend, gitlint install-hook auszuführen, um den gitlint Commit-Message-Hook (oder pipenv run gitlint install-hook mit Pipenv-Setups) zu installieren.
Wenn der Haken wie oben beschrieben installiert ist, wird nach Abschluss des Textes für ein Commit von Gitlint gegen den von uns eingerichteten Stil überprüft, und gibt Ratschläge an, wenn es Probleme gibt, die er bemerkt. Wenn Gitlint eine findet, wird gefragt, ob Sie sich mit der Nachricht so begnügen möchten ( y für "Ja"), stoppen Sie den Commit -Prozess ( n für "Nein") oder bearbeiten Sie die Commit -Nachricht ( e für "Bearbeiten").
Während der Inhalt immer noch von Ihren Schreibfähigkeiten abhängt, stellt dies eine konsistentere Formatierungsstruktur zwischen Commits, einschließlich verschiedener Autoren, sicher.
Tests für Zulip-terminal werden unter Verwendung von PyTest geschrieben. Sie können die Tests im Ordner /tests lesen, um das Schreiben von Tests für eine neue Klasse /Funktion zu erhalten. Wenn Sie neu in PyTest sind, wird definitiv empfohlen, seine Dokumentation zu lesen.
Wir haben derzeit Tausende von Tests, die über das Ausführen von pytest geprüft werden. Dies ist zwar von Ihrer Systemfähigkeit abhängig, aber es sollte in der Regel weniger als eine Minute dauern. Während des Debuggens möchten Sie jedoch noch den Umfang Ihrer Tests einschränken, um die Abwicklungszeit zu verbessern:
Wenn viele Tests sehr ausführlich ausfallen, versuchen Sie möglicherweise die Option -x (z. B. pytest -x ), um Tests nach dem ersten Fehler zu stoppen. Aufgrund der Parametrisierung von Tests und Testvorrichtungen können viele offensichtliche Fehler/Fehler mit nur einem Fix aufgelöst werden! (Versuchen Sie, z. B. pytest --maxfail 3 für eine weniger strenge Version davon)
Um nicht alle erfolgreichen Tests zusammen mit den Fehlern durchzuführen, können Sie mit --lf (z. B. pytest --lf ) ausgeführt werden, kurz für --last-failed (ähnliche nützliche Optionen können --failed-first und --new-first , was möglicherweise gut mit -x passt).
Da PyTest 3.10 --sw ( --stepwise ) gibt, das bekannte Fehler auf die gleiche Weise wie --lf und -x verwendet werden kann, was mit --stepwise-skip kombiniert werden kann, um zu steuern, welcher Test der aktuelle Fokus ist
Wenn Sie die Namen von Tests kennen, die fehlschlagen und/oder an einem bestimmten Ort, können Sie Tests auf einen bestimmten Ort beschränken (z. B. pytest tests/model ) oder ein ausgewähltes Schlüsselwort (z. B. pytest -k __handle ) verwenden.
Wenn nur eine Teilmenge von Tests ausgeführt wird, wird es praktischer und nützlicher, die Option -v ( --verbose ) zu verwenden. anstatt a zu zeigen . (oder F , E , x usw.) Für jedes Testergebnis ergibt es den Namen (mit Parametern) jedes Tests (z. B. pytest -v -k __handle ). Diese Option zeigt auch Details in Tests und kann mehrmals angegeben werden (z. B. pytest -vv ).
Weitere Hilfe bei PyTest -Optionen finden Sie pytest -h oder finden Sie die vollständigen PyTest -Dokumentation.
print Der STDOut (Standardausgang) -d Zulip --debug terminal wird nach ./debug.log
Dies bedeutet, dass Sie einfach print() verwenden können, z.
print ( f"Just about to do something with { variable } " ) Und wenn Sie mit einer Debugging -Option ausgeführt werden, wird die Zeichenfolge auf ./debug.log gedruckt.
Mit einem bash -ähnlichen Terminal können Sie in einem anderen Terminal so etwas wie tail -f debug.log ausführen, um die Ausgabe aus print zu sehen, wie es passiert.
Wenn Sie während des Laufens Zulip-Terminal debuggen möchten oder in einem bestimmten Zustand, können Sie einfügen
from pudb . remote import set_trace
set_trace () Im Teil des Code möchten Sie debuggen. Dies startet eine Telnet -Verbindung für Sie. Sie finden die IP -Adresse und den Port der Telnet -Verbindung in ./debug.log . Dann einfach rennen
$ telnet 127.0.0.1 6899
In einem anderen Terminal, wobei 127.0.0.1 die IP -Adresse und 6899 ist, die Sie in ./debug.log finden.
Dies bedeutet wahrscheinlich, dass Sie sowohl normale als auch Entwicklungsversionen von Zulip-terminal installiert haben.
Um sicherzustellen, dass Sie die Entwicklungsversion ausführen:
Wenn Sie Pipenv verwenden, rufen Sie pipenv run zulip-term aus dem geklonten/heruntergeladenen zulip-terminal Verzeichnis aus.
Wenn Sie PIP (PIP3) verwenden, stellen Sie sicher, dass Sie die richtige virtuelle Umgebung (Venv) aktiviert haben. Abhängig davon, wie Ihre Shell konfiguriert ist, kann der Name des Venv in der Eingabeaufforderung angezeigt werden. Beachten Sie, dass -e auch dieses Problem verursacht.
