zulip terminal
Zulip Terminal 0.7.0
最近の変更|構成|ホットキー| FAQS |開発|チュートリアル
Zulipターミナルは、Zulipの公式ターミナルクライアントであり、テキストベースのユーザーインターフェイス（TUI）を提供します。
特定の目的は次のとおりです。
チュートリアルでZulipターミナルの使用方法を学びます。
私たちは、クライアントがすでにかなり安定した中程度に特徴のある日常ユーザーエクスペリエンスを提供することを検討しています。
現在の開発の焦点は、より一般的に使用されている日常の使用の側面を改善することにあります - ユーザーが特定の機能のために一時的に別のクライアントに切り替える必要性を減らすことです。
長期的にのみ解決すると予想される現在の制限には、以下のサポートが含まれます。
端末クライアントは現在、Zulip Webクライアントに多くの意図的な違いを持っています。
機能サポートの欠落のクエリについては、よくある質問（FAQ）、オープンな問題、またはZulip Community Serverでオンラインでユーザーと開発者とチャットしてください！
専用のPython仮想環境（以下を参照）にインストールするか、PIPXなどの自動オプションを使用することをお勧めします
安定したリリース- これらはパッケージZulip -TermとしてPypiで利用可能です
インストールするには、次のようなコマンドを実行します。PIP3 pip3 install zulip-term
最新の（git）バージョン- 最新の開発バージョンは、gitリポジトリmainブランチからインストールできます
インストールするには、 pip3 install git+https://github.com/zulip/zulip-terminal.git@main
また、Docker/にDocker画像を作成するためのサンプルDockerFilesも提供します。
実行に必要なPython 3.6+を使用すると、以下はほとんどのシステムで動作するはずです。
python3 -m venv zt_venv （現在のディレクトリにzt_venvという名前の仮想環境を作成します）source zt_venv/bin/activate （仮想環境をアクティブ化します。これはバッシュのようなシェルを想定しています）別の端末ウィンドウ（またはコンピューターのログオフ/再起動）を開くと、 zulip-termを実行する前に上記のリストのステップ2を再度実行する必要があります。 Python 3 Library Venvドキュメントで、仮想環境の詳細を読むことができます。
自動更新システムがないことに注意してください。インストールバージョンに関連する更新場所を追跡してください。
安定したリリース
アップグレードする前に、最近のリリースの変更を確認することをお勧めします。そうすれば、リリース間の重要な変更を認識してください。
これらは現在、Zulip Community Server（https://chat.zulip.org）の＃Announce >ターミナルリリーストピックで発表されています。これは、アカウントなしで表示されます。
更新が発表されたときにメールを受信したい場合は、このサーバーのアカウントにサインアップすることをお勧めします。これにより、 #Announceストリームの電子メール通知（help article、chat.zulip.orgの通知設定）を有効にすることができます。
また、プロジェクトページでGitHub Watchの設定をカスタマイズして、リリースを含めることもできます。
PypiはRSSリリースフィードを提供し、その他のさまざまなサービスはこの情報を追跡します。
最新の（git）バージョン
main Gitブランチからインストールされたバージョンも自動的に更新されません - 「最新」は、インストール時点でのステータスを指します。
これは、他のソースまたは開発インストール（例：https://aur.archlinux.org/packages/python-zulip-term-git/）にも適用されます。
したがって、上記のコマンド、またはパッケージシステムに関連するコマンド（例：Arch）を使用してパッケージをアップグレードします。
mainブランチは安定したままであることを目的としていますが、2つのarbitrary意的な「最新」バージョン間でアップグレードする場合は、変更は要約されていないことに注意してください。
zulip-term最初に実行すると、 zuliprcファイルを探します。デフォルトでは、Zulipサーバーにログインする詳細が含まれています。
このファイルが見つからない場合は、2つのオプションがあります。
zulip-term 、サーバー、電子メール、パスワードのためにお客様を促し、その場所でzuliprcファイルを作成します
注： Google、Github、またはその他の外部認証を使用してZulip組織にアクセスすると、パスワードセットがなく、現在Zulip-Terminalを使用するために作成する必要があります。
<Zulip server URL>/accounts/password/reset/に相当するものに移動して、アカウントの新しいパスワードを作成してください（https://chat.zulip.org/accounts/password/reset/）。 zulip-term実行するたびに、 -cまたは--config-fileオプションを使用して、代替zuliprcファイルへのパスを指定できます。 $ zulip-term -c /path/to/zuliprc
特定のZULIPサーバー上のアカウントに対応する.zuliprcファイルは、そのサーバーに接続されたWebまたはデスクトップアプリケーションを介してダウンロードできます。最近のバージョンでは、 APIキーの下の「APIキーを表示/変更」として、アカウントおよびプライバシーセクションの個人設定にあります。
これが唯一のZulipアカウントである場合は、このファイルを上のデフォルトのファイルの場所に移動して名前を変更するか、 ---config-fileオプションに渡すことができるより記憶に残るものに名前を変更することをお勧めします。この.zuliprcファイルは、そのユーザーとして持っているすべての許可を提供します。
同様の.zuliprc filesセットアップしたボットのボットセクションからダウンロードできますが、それに応じてアクセス許可が限られています。
注：サーバーがセルフ署名証明書または不安定な接続を使用している場合、 zuliprcファイルに追加のオプションを手動で追加する必要があります - Zulip Pythonモジュールのドキュメントを参照してください。
-eまたは--exploreオプション（Exploreモード）を使用してzulip-termを実行することをお勧めします。チュートリアルと一緒にフォローして、物事を理解してみてください。
zuliprcファイルには2つのセクションが含まれています。
[api]セクションzulip-termに固有の構成を備えた[zterm]セクション最初のセクションのみを備えたファイルは、場合によってはzulip-termによって自動生成できます。または、サーバー上のアカウントから1つをダウンロードできます（上記参照）。 2番目のセクションの一部はzulip-termの動作をカスタマイズするときに段階的に追加および調整できます。
以下の例は、ダミー[api]セクションの内容を使用して、すべてのデフォルトの互換性のある[zterm]値を伴うすべてのデフォルトの[zterm]値を持つ作業構成ファイルを表し、付随するメモを表します。
[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
注：これらの構成設定のほとんどは
zulip-termが開始されたときにコマンドラインに指定される場合があります。zulip-term -hまたはzulip-term --helpオプションの完全なリストを提供します。
現在、通知はWSLでサポートされていないことに注意してください。 ＃767を参照してください。
次のコマンドは、Debianベースのシステムにnotify-sendをインストールします。他のLinuxシステムについても同様のコマンドを見つけることができます。
sudo apt-get install libnotify-bin
OS Xで通知を有効にするには、追加のパッケージは必要ありません。ただし、通知音がするには、次の変数を設定します（シェルの種類に基づいて）。 Sound値（ここではping）は/System/Library/Soundsまたは~/Library/Soundsで見つかった.aiffファイルのいずれかです。
バッシュ
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.bash_profile
source ~/.bash_profile
zsh
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.zshenv
source ~/.zshenv
Zulipターミナルを使用すると、ユーザーは特定のテキストをPyperclipであるPyperClipを介してクリップボードにコピーできます。このモジュールは、OSに付属する場合と搭載されていない場合があるさまざまなシステムパッケージを使用しています。 「Copy to Clipboard」機能は現在、Stream Information PopupからStream Emailのコピーのみを使用できます。
Linuxでは、このモジュールはxclipまたはxselコマンドを使用します。これはすでにOSに付属するはずです。これらのコマンドがシステムにインストールされていない場合は、以下を使用してインストールしてください。
sudo apt-get install xclip [Recommended]
または
sudo apt-get install xsel
クリップボードへのコピーを有効にするために、追加のパッケージは必要ありません。
ZulipターミナルはZulipサーバーと連携するように設計されていますが、主な貢献者はhttps://chat.zulip.orgのZulipコミュニティサーバーに存在し、 ＃Zulip末端ストリームでほとんどの会話があります。
上記のリンクを使用してそのストリームで会話を表示するか、アカウントにサインアップしてユーザーであろうと開発者であろうとチャットしてください！
Zulipコミュニティを友好的で歓迎し、生産的に保つことを目指しているので、参加している場合は、コミュニティの規範を尊重してください。
これらは、上記のリンクされているコミュニティ規範のサブセットであり、Zulipターミナルのユーザーにより関連しています。テキスト環境にある可能性が高く、文字列/列に限定され、この1つの小さなストリームに存在する可能性があります。
スクリーンショットの代わりに、コードブロックのテキストを好みます
Zulip Terminalは画像のダウンロードをサポートしていますが、ユーザーがそれらを表示できるという保証はありません。
メタ+ mを試して、コードブロックを含むコンテンツのフォーマットの例を確認してください
定期的な言及よりも静かな言及を好む - または完全に言及を避ける
Zulipのトピックを使用すると、意図した受信者は既に明確になっていることがよくあります。経験豊富なメンバーは、時間の許可として存在します - 戻ってきたときにメッセージに応答する - そして、それ以前に他の人が支援することができるかもしれません。
（定期的に出席することを期待していない人のために定期的な言及を保存してください）
@_を入力してサイレント指定を指定した後、メッセージコンテンツのオートコンプリートを介してCTRL + F / Bを試してみてください
引用符のトリミングを好み、長いメッセージの関連部分のみにテキストを返信するか、完全に引用しないようにします
Zulipのトピックは、多くの場合、どのメッセージに返信しているかを明確にします。長いメッセージは、限られた行とテキストの列で読みにくい場合がありますが、これは、追加のコンテンツを含む長いメッセージ全体を引用すると悪化します。
選択したメッセージを引用して、メッセージを作成するときに通常どおりにテキストを削除してみてください
単純な短いメッセージの代わりに合意を示すために、簡単な絵文字反応を好む
特に複数のユーザーが同じ感情で応答したい場合は、Zulipターミナルを含め、反応が少ないスペースを占有します。
メッセージで親指（+1）を切り替えるか、使用するか：他の反応を検索する
Zulipターミナルは、素晴らしいZulipコミュニティによって構築されています。
その一部であり、コードに貢献するには、＃Zulip-Terminalで問題に取り組んだり、アイデアを提案したりしてください。
コミット構造とスタイルについては、以下のコミットスタイルセクションを確認してください。
gitを初めて使用する（またはそうでない！）、Zulip Gitガイドの恩恵を受けることができます。貢献するときは、リベース指向のワークフローを使用していることに注意することが重要です。
typingインジケーターを実装するための簡単なチュートリアルが利用できます。 Zulip-Terminalの新機能を実装する方法を理解するためにそれに従ってください。
もちろん、ダウンロードするGitHubとソースツリーのソースを閲覧し、ファイルの現在の配置のアイデアについてソースファイルの概要を確認できます。
Zulipターミナルは、URWIDを使用してUIコンポーネントを端子にレンダリングします。 Urwidは、Pythonを使用してまともな端末UIをレンダリングできる素晴らしいライブラリです。 Urwidのチュートリアルは、新しい貢献者にとって始めるのに最適な場所です。
まず、GitHubのzulip/zulip-terminalリポジトリをフォークし（方法を参照）、フォークリポジトリをローカルにクローンし、 Your_UsernameをGitHubユーザー名に置き換えます。
$ git clone --config pull.rebase [email protected]:YOUR_USERNAME/zulip-terminal.git
これにより、現在のディレクトリにリポジトリの新しいディレクトリが作成されるため、 cd zulip-terminalでリポジトリディレクトリを入力し、Zulipターミナルのクローンフォーク用の上流のリモートリポジトリを構成してフェッチします。
$ git remote add -f upstream https://github.com/zulip/zulip-terminal.git
クローニングと上流のセットアップに使用されるコマンドの詳細な説明については、ZulipのGitガイドのGet Zulipコードセクションのステップ1を参照してください。
さまざまなオプションが利用可能です。私たちはそれぞれの利点を模索しており、あなたが使用しているか、最も効果的であると感じているフィードバックに感謝します。
それぞれの場合に使用されるツールは通常同じですが、異なる方法で呼ばれていることに注意してください。
次のコマンドは、前のセクションのプロセスと同様のプロセスによって作成されたリポジトリディレクトリで実行する必要があります。
$ pip3 install --user pipenv
--python 3.6を使用します。 $ pipenv --three
$ pipenv install --dev
$ pipenv run pip3 install -e '.[dev]'
$ pipenv run gitlint install-hook
仮想環境を手動で作成およびアクティブ化します。上記の簡単なインストールで使用されているような方法は機能するはずです
python3 -m venv zt_venv （現在のディレクトリにzt_venvという名前のvenvを作成）source zt_venv/bin/activate （venvをアクティブ化します。これはバッシュのようなシェルを想定しています）開発要件を使用して、Zulip-Termをインストールします
$ pip3 install -e '.[dev]'
$ gitlint install-hook
これは、インストールmakeている場合、最新かつ最も簡単なアプローチです。
make （現在のディレクトリのzt_venvにインストールされた仮想環境を設定します）source zt_venv/bin/activate （venvをアクティブ化します。これはバッシュのようなシェルを想定しています）gitlint install-hook （gitlintコミットメサージフックを接続）開発環境が設定されたら、環境の種類に応じて、次のように役立つことがあります。
| タスク | make＆pip | pipenv |
|---|---|---|
| 正常に実行します | zulip-term | pipenv run zulip-term |
| デバッグモードで実行します | zulip-term -d | pipenv run zulip-term -d |
| プロファイリングで実行します | zulip-term --profile | pipenv run zulip-term --profile |
| すべてのリンジターを実行します | ./tools/lint-all | pipenv run ./tools/lint-all |
| すべてのテストを実行します | pytest | pipenv run pytest |
| テストカバレッジレポートを作成します | pytest --cov-report html:cov_html --cov=./ | pipenv run pytest --cov-report html:cov_html --cov=./ |
PIPでMakeを使用する場合、Runn make 、GITからフェッチしてリベッシングした後に有用な、指定された依存関係とともに開発環境が最新になるようにします。
お気に入りのテキストエディターまたは開発環境を選択してください！
ソースには、多くのエディターがプロジェクトの最小要件を満たすファイルを作成するように自動的に自分自身を構成できるようにする.editorconfigファイルが含まれています。編集者サポートについては、https：//editorconfig.orgを参照してください。この機能を使用する場合は、プラグインが必要になる場合があるものがある場合があります。
リナーと自動テスト（pytest）は、プルリクエスト（PR）を送信するときにCI（GitHubアクション）で自動的に実行されるか、既存のプルリクエストに変更をプッシュします。
ただし、コンピューターでこれらのチェックを実行すると、コードをgithubに繰り返しプッシュする必要性を回避することで、開発をスピードアップできます。これを達成するためのコマンドは、上記の開発タスクの表にリストされています（個々のリナーは、 tools/のスクリプトを介して実行される場合があります）。
さらに、 makeベースのシステムを使用する場合：
make lint 、 make testタスクのすべてのグループのすべてのグループmake check 。これはPR（または更新）をプッシュする前に役立ちますtools/check-branchが実行され、ブランチでの各コミットをmake check注：一人一人ベースを含めて、すべてのリナーとテストが通過するまで、プルリクエストがマージされる可能性は非常に低いです。
いくつかの糸くずエラーを修正するには、タイプチェックのためのmypyからのような手動介入が必要です。
テストのヒントについては、Pytestに関する以下のセクションをさらに確認してください。
ただし、以下に詳述するように、他の糸くずエラーは自動的に修正される場合があります。これにより、リンターを渡すためにコードを手動で調整する時間を節約できます。
LinterまたはPytestが失敗している理由を理解するのに問題がある場合は、コードをブランチ/PRにプッシュしてください。PRまたはchat.zulip.orgで問題について話し合うことができます。
これらを更新する場合は、糸くずに合格するために両方の場所のテキストを手動で更新する必要はないことに注意してください。
真実のソースはソースコードにあるため、Pythonファイルを更新して関連するツールを実行するだけです。現在、私たちは持っています：
tools/lint-hotkeys --fix docs/hotkeys.mdをconfig/keys.pyから再生成するためにtools/lint-docstring --fixファイルドキュストリングスからDocs/Developer-File-overview.mdを再生成するために（これらのツールは、これらのファイルが同期していることを確認するために、糸くずプロセスにも使用されます）
このプロジェクトでは、それぞれコードスタイルとインポートソートにblackとisortを使用しています。
これらのツールは、ローカルでリンジターとして実行できますが、コードを自動的にフォーマットすることもできます。
makeベースのセットアップを使用している場合、Runn make fix両方（および他のいくつかのツール）を実行し、コードの現在の状態を再--amendします。
また、ファイルまたはディレクトリでツールを個別に使用することもできます。 black zulipterminalまたはisort tests/model/test_model.py
地元で作業し、変更を調査するための調査を調査すると、進捗状況を保存するために一連の小さなコミットを作成することが一般的です。多くの場合、これには、以前のコミットで糸くずまたはテストの問題を修正するコミットが含まれます。これらは発達スタイルのコミットです - そして、ほとんどの人は、このスタイルである程度コミットを書く可能性があります。
発達スタイルのコミットは、今あなたのために変更をうまく保管しています。ただし、コードを共有するとき、コミットメッセージは、あなたが変えているものとその理由を他の人に伝えるのに最適な場所です。構造を片付けることは、読者が変化を理解し、あなたが彼らの時間を尊重することをより簡単かつ迅速にすることができます。 1つの例は、非常に大きなシングルコミットがレビューに多くの時間がかかる場合があることです。もう1つは、テスト/リントをコミットで修正した場合です。どのコミット（またはコミット！）を修正しますか？これは、同じブランチ/PRにある場合、元のコミットが代わりに修正されていないのはなぜですか？
したがって、プルリクエスト（PR）を作成するときは、読み取り、理解、レビューが簡単になる場合は、コードがより迅速にマージされる可能性が高いことを考えてください。その大部分は、コミットに変更を構築し、コミットメッセージの変更を説明する方法です。
PRSをレビューして更新しやすくするために、PRSがZulipや他の場所で取られたアプローチに従って、PRが一連の最小限のコヒーレントコミットで構成されることを目指しています。
これらの原則を維持することは、次のことを含む、PRの前、最中、レビューの両方で他の利点を与えることができることに注意してください。
mainのgit bisectのユーティリティが向上します現在、私たちは、継続的な統合（CI）の一環として、仕事のPRでコミットの一貫した性質の限られた側面を実施し、孤立したPRコミットを確保しますmake check tools/check-branchを使用してGitHubにプッシュする前に、これをローカルに複製できます。
小規模または概念実証PRSは、最初はそのままプッシュすることは問題ありませんが、全体的な変更に基づいてのみレビューされる可能性があります。一般的に、個々のコミットが発達スタイルを持っているように見える場合、レビュアーはより少ない特定のフィードバックを与える可能性が高く、合併前に最小限の一貫したコミットが要求されることは確実です。
再構築コマンド- ほとんどの再編は、インタラクティブなリベッシング（例： git rebase -i upstream/main ）に依存していますが、特定のアクションをオンラインで検索したり、 #GITヘルプを検索したり尋ねたりすることを検討してください。
セルフレビュー- もう1つの有用なアプローチは、地元でのコミットをレビューすることです（Zulipの提案を参照）とGithubにプッシュした後。これにより、場所の外に見えるものを検査して修正することができます。誰かがレビューで拾う可能性が高いため、提出物がより洗練されているようになり、再びレビュアーの時間を尊重することを示します。
git log一貫して読みやすくするために、標準的なコミットスタイルに従うことを目指しています。
コードを操作するのと同じように、積極的に使用しているスタイルの例については、Gitログの最近のコミットを参照することをお勧めします。
コミットメッセージの全体的なスタイルは、Zulipコミットメッセージに与えられた一般的なガイドラインに広く従うため、最初に読むことをお勧めします。
私たちのコミットタイトル（要約）には、一般的なZulipスタイルからわずかなバリエーションがあります。
/で区切られています。Tests updatedまたはコミットテキストにTests added ）refactor: 、 bugfix:およびrequirements:以下を参照）タイトルをコミットする例：（理想的には実際に説明的です！）
file3/file1/file2: Improve behavior of something.file1.txt 、 file2.pyおよびfile3.mdrefactor: file1/file2: Extract some common function.file1.pyとfile2.pyを含む機能的動作を変更しない純粋なリファクタルbugfix: file1: Avoid some noticeable bug.file1.pyでバグを修正するための小さなコミットtests: file1: Improve test for something.test_file1.pyでは、 file1のテストのみを改善しますrequirements: Upgrade some-dependency from ==9.2 to ==9.3.これらのルールのいくつかを満たすのを支援するために、次のセクションで説明するように、 GitLint使用できます。
ただし、Gitlintは言語や文法を含むすべてをチェックできないため、これらのスタイルのルールに対して手動でコミットをチェックしてください！
gitlintツールは、デフォルトで開発環境にインストールされており、コミットが予想される基準を満たすことを保証することができます。
このツールは、特定のコミットを手動で確認できます。最新のコミットのためのgitlint 、またはgitlint --commits main.. mainからのコミット用。ただし、 gitlint Commit-Messageフック（またはPipenvセットアップを備えたpipenv run gitlint install-hook ）をインストールするために、 gitlint install-hookを実行することを強くお勧めします。
上記のようにフックがインストールされている場合、コミットのためにテキストを完成させた後、Gitlintによって設定したスタイルに対してチェックされ、気づいた問題がある場合はアドバイスを提供します。 gitlintが何かを見つけた場合、メッセージでコミットしたい（ y for' yes '）、コミットプロセス（ n for' no '）を停止するか、コミットメッセージを編集するか（ e for 'edit'）編集します。
コンテンツは依然としてライティングスキルに依存しますが、これにより、異なる著者を含むコミット間のより一貫したフォーマット構造が保証されます。
Zulip-Terminalのテストは、Pytestを使用して記述されます。 /testsフォルダーのテストを読んで、新しいクラス /機能のテストの作成について学ぶことができます。 Pytestを初めて使用する場合は、ドキュメントを読むことをお勧めします。
現在、 pytestの実行時にチェックされる数千のテストがあります。システム機能に依存しますが、これは通常、実行に1分未満かかるはずです。ただし、デバッグ中は、テストの範囲を制限して、ターンアラウンド時間を改善することをお勧めします。
多くのテストが非常に冗長な方法で失敗している場合、最初の障害後にテストを停止するために-xオプション（例： pytest -x ）を試すことができます。テストとテストフィクスチャーのパラメーター化により、1つの修正だけで多くの明らかなエラー/障害を解決できます！ （例えば、 pytest --maxfail 3 ）
毎回すべての成功したテストを実行しないように、 --last-failedとともに--failed-first --lf （例えば--new-first pytest --lf ）で実行でき-x 。
pytest 3.10であるため、 --sw （ --stepwise ）があります。これは、 --lfと-xを使用できるのと同じ方法で既知の障害を介して機能します--stepwise-skip
故障している、および/または特定の場所でテストの名前を知っている場合、テストを特定の場所（例： pytest tests/model ）に制限するか、選択したキーワード（例： pytest -k __handle ）を使用する場合があります。
テストのサブセットのみが実行されている場合、 -vオプション（ --verbose ）を使用する方がより実用的で便利になります。を表示する代わりに. （またはF 、 E 、 xなど）各テスト結果について、実行中の各テストの名前（パラメーターを使用）を与えます（例： pytest -v -k __handle ）。また、このオプションはテストの詳細を示しており、複数回（例： pytest -vv ）を与えることができます。
Pytestオプションの追加ヘルプについては、 pytest -hを参照するか、完全なPytestドキュメントをご覧ください。
printを使用した出力Zulip-Terminalのstdout（標準出力）は、 -dまたは--debugを使用して実行時にデバッグが有効になっている場合./debug.logにリダイレクトされます。
これは、変数の値を確認する場合、またはコードの特定のポイントに到達することを示す場合、単にprint()を使用できることを意味します。
print ( f"Just about to do something with { variable } " )また、デバッグオプションで実行するとき、文字列は./debug.logに印刷されます。
バッシュのような端末を使用すると、別の端末でtail -f debug.logのようなものを実行して、発生したときにprintを表示できます。
Zulip-Terminalが実行中にデバッグしたい場合、または特定の状態で挿入できます
from pudb . remote import set_trace
set_trace ()コードの部分では、デバッグしたいです。これにより、Telnet接続が開始されます。 Telnet接続のIPアドレスとポートを./debug.logで見つけることができます。次に、単に実行します
$ telnet 127.0.0.1 6899
別の端末では、 127.0.0.1がIPアドレスであり、 6899 ./debug.logにあるポートです。
これは、Zulip-Terminalの通常のバージョンと開発バージョンの両方をインストールしたことを意味する可能性があります。
開発バージョンを実行することを確認するには：
pipenvを使用する場合は、クローン/ダウンロードされたzulip-terminalディレクトリからpipenv run zulip-termを呼び出します。
PIP（PIP3）を使用している場合は、正しい仮想環境（VENV）をアクティブにしたことを確認してください。シェルの構成方法によっては、venvの名前がコマンドプロンプトに表示される場合があります。 PIP3コマンドに-eを含めないとこの問題が発生することに注意してください。
