zulip terminal
Zulip Terminal 0.7.0
Perubahan Terbaru | Konfigurasi | Kunci Panas | FAQ | Pembangunan | Tutorial
Zulip Terminal adalah klien terminal resmi untuk Zulip, menyediakan antarmuka pengguna berbasis teks (TUI).
Tujuan khusus meliputi:
Pelajari cara menggunakan terminal zulip dengan tutorial kami.
Kami menganggap klien sudah memberikan pengalaman pengguna sehari-hari yang cukup stabil.
Fokus pengembangan saat ini adalah pada peningkatan aspek penggunaan sehari -hari yang lebih umum digunakan - untuk mengurangi kebutuhan pengguna untuk sementara waktu beralih ke klien lain untuk fitur tertentu.
Keterbatasan saat ini yang kami harapkan hanya akan diselesaikan dalam jangka panjang termasuk dukungan untuk:
Klien Terminal saat ini memiliki sejumlah perbedaan yang disengaja dengan klien web Zulip:
Untuk pertanyaan tentang dukungan fitur yang hilang, silakan lihat pertanyaan yang sering diajukan (FAQ), masalah terbuka kami, atau obrolan dengan pengguna & pengembang online di Zulip Community Server!
Kami sarankan menginstal di lingkungan virtual Python khusus (lihat di bawah) atau menggunakan opsi otomatis seperti PIPX
Rilis Stabil - Ini tersedia di PYPI sebagai paket zulip -istilah
Untuk menginstal, jalankan perintah seperti: pip3 install zulip-term
Versi Terbaru (GIT) - Versi pengembangan terbaru dapat diinstal dari cabang main Git Repository
Untuk menginstal, jalankan perintah seperti: pip3 install git+https://github.com/zulip/zulip-terminal.git@main
Kami juga menyediakan beberapa sampel dockerfiles untuk membangun gambar Docker di Docker/.
Dengan Python 3.6+ yang diperlukan untuk berjalan, berikut ini harus bekerja pada sebagian besar sistem:
python3 -m venv zt_venv (menciptakan lingkungan virtual bernama zt_venv di direktori saat ini)source zt_venv/bin/activate (mengaktifkan lingkungan virtual; ini mengasumsikan shell seperti bash) Jika Anda membuka jendela terminal yang berbeda (atau log-off/restart komputer Anda), Anda harus menjalankan langkah 2 dari daftar di atas lagi sebelum menjalankan zulip-term , karena itu mengaktifkan lingkungan virtual itu. Anda dapat membaca lebih lanjut tentang lingkungan virtual di dokumentasi VENV perpustakaan Python 3.
Perhatikan bahwa tidak ada sistem pembaruan otomatis, jadi harap lacak lokasi pembaruan yang relevan dengan versi instalasi Anda:
Pelepasan stabil
Sebelum meningkatkan, kami sarankan Anda memeriksa perubahan dalam rilis terbaru sehingga Anda mengetahui adanya perubahan penting antara rilis.
Ini sekarang diumumkan di # pengumuman> Terminal Rilis Topik di Zulip Community Server (https://chat.zulip.org), yang terlihat tanpa akun.
Jika Anda ingin menerima email saat pembaruan diumumkan, Anda dipersilakan untuk mendaftar untuk akun di server ini, yang akan memungkinkan Anda untuk mengaktifkan pemberitahuan email untuk aliran #Announce (artikel bantuan, pengaturan pemberitahuan di chat.zulip.org).
Anda juga dapat menyesuaikan pengaturan jam tangan GitHub Anda di halaman proyek untuk memasukkan rilis.
PYPI menyediakan umpan rilis RSS, dan berbagai layanan lainnya melacak informasi ini.
Versi terbaru (git)
Versi yang diinstal dari cabang main Git juga tidak akan memperbarui secara otomatis - 'terbaru' mengacu pada status pada titik instalasi.
Ini juga berlaku untuk instalasi sumber atau pengembangan lain (mis. Https://aur.archlinux.org/packages/python-zulip-term-mit-git/).
Oleh karena itu, tingkatkan paket Anda menggunakan perintah di atas, atau satu yang berkaitan dengan sistem paket Anda (mis. Arch).
Sementara cabang main dimaksudkan untuk tetap stabil, jika meningkatkan antara dua versi 'terbaru' yang sewenang -wenang, harap diketahui bahwa perubahan tidak diringkas , meskipun log komit kami harus sangat mudah dibaca.
Setelah pertama kali menjalankan zulip-term ia mencari file zuliprc , secara default di direktori home Anda, yang berisi detail untuk masuk ke server Zulip.
Jika tidak menemukan file ini, Anda memiliki dua opsi:
zulip-term akan meminta Anda untuk server, email, dan kata sandi Anda, dan membuat file zuliprc untuk Anda di lokasi itu
Catatan: Jika Anda menggunakan Google, GitHub atau otentikasi eksternal lainnya untuk mengakses organisasi Zulip Anda maka Anda mungkin tidak akan memiliki set kata sandi dan saat ini perlu membuat satu untuk menggunakan zulip-terminal.
<Zulip server URL>/accounts/password/reset/ untuk membuat kata sandi baru untuk akun Anda (misalnya: https://chat.zulip.org/accounts/password/reset/). Setiap kali Anda menjalankan zulip-term , Anda dapat menentukan jalur ke file zuliprc alternatif menggunakan opsi -c atau --config-file , misalnya. $ zulip-term -c /path/to/zuliprc
File .zuliprc yang sesuai dengan akun Anda di server Zulip tertentu dapat diunduh melalui aplikasi web atau desktop yang terhubung ke server itu. Dalam versi terbaru ini dapat ditemukan di pengaturan pribadi Anda di bagian Akun & Privasi , di bawah Kunci API sebagai 'Tampilkan/Ubah Kunci API Anda'.
Jika ini satu-satunya akun Zulip Anda, Anda mungkin ingin memindahkan dan mengganti nama file ini ke lokasi file default di atas, atau mengganti nama menjadi sesuatu yang lebih mengesankan yang dapat Anda lewati ke opsi ---config-file . File .zuliprc ini memberi Anda semua izin yang Anda miliki sebagai pengguna itu.
.zuliprc files serupa dapat diunduh dari bagian bot untuk setiap bot yang telah Anda atur, meskipun dengan izin terbatas yang sesuai.
Catatan: Jika server Anda menggunakan sertifikat yang ditandatangani sendiri atau koneksi yang tidak aman, Anda perlu menambahkan opsi tambahan ke file zuliprc secara manual - lihat dokumentasi untuk modul Zulip Python.
Kami menyarankan menjalankan zulip-term menggunakan opsi -e atau --explore (dalam mode penjelasan) ketika Anda mencoba terminal zulip untuk pertama kalinya, di mana kami sengaja tidak menandai pesan seperti yang dibaca. Cobalah mengikuti tutorial kami untuk memahami banyak hal.
File zuliprc berisi dua bagian:
[api] dengan informasi yang diperlukan untuk terhubung ke server Zulip Anda[zterm] dengan konfigurasi khusus untuk zulip-term File dengan hanya bagian pertama yang dapat dihasilkan secara otomatis dalam beberapa kasus dengan zulip-term , atau Anda dapat mengunduh satu dari akun Anda di server Anda (lihat di atas). Bagian dari bagian kedua dapat ditambahkan dan disesuaikan secara bertahap ketika Anda ingin menyesuaikan perilaku zulip-term .
Contoh di bawah ini, dengan konten bagian [api] dummy, mewakili file konfigurasi kerja dengan semua nilai [zterm] yang kompatibel default tidak dikomentasikan dan dengan catatan yang menyertainya:
[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
Catatan: Sebagian besar pengaturan konfigurasi ini dapat ditentukan pada baris perintah ketika
zulip-termdimulai;zulip-term -hatauzulip-term --helpakan memberikan daftar lengkap opsi.
Perhatikan bahwa pemberitahuan saat ini tidak didukung di WSL; Lihat #767.
Perintah berikut menginstal notify-send pada sistem berbasis Debian, perintah serupa juga dapat ditemukan untuk sistem Linux lainnya.
sudo apt-get install libnotify-bin
Tidak ada paket tambahan yang diperlukan untuk mengaktifkan pemberitahuan di OS X. Namun untuk memiliki suara pemberitahuan, atur variabel berikut (berdasarkan jenis shell Anda). Nilai suara (di sini ping) dapat berupa salah satu dari file .aiff yang ditemukan di /System/Library/Sounds atau ~/Library/Sounds .
Pesta
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.bash_profile
source ~/.bash_profile
Zsh
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.zshenv
source ~/.zshenv
Zulip Terminal memungkinkan pengguna untuk menyalin teks tertentu ke clipboard melalui modul Python, Pyperclip . Modul ini memanfaatkan berbagai paket sistem yang mungkin atau mungkin tidak datang dengan OS. Fitur "Salin ke Clipboard" saat ini hanya tersedia untuk menyalin email aliran, dari popup informasi aliran.
Di Linux, modul ini menggunakan perintah xclip atau xsel , yang seharusnya sudah datang dengan OS. Jika tidak satu pun dari perintah ini yang diinstal pada sistem Anda, maka instal siapa pun menggunakan:
sudo apt-get install xclip [Recommended]
ATAU
sudo apt-get install xsel
Tidak ada paket tambahan yang diperlukan untuk mengaktifkan penyalinan ke clipboard.
Sementara Zulip Terminal dirancang untuk bekerja dengan server Zulip mana pun, kontributor utama hadir di server komunitas Zulip di https://chat.zulip.org, dengan sebagian besar percakapan di aliran terminal #zulip .
Anda dipersilakan untuk melihat percakapan di aliran itu menggunakan tautan di atas, atau mendaftar untuk akun dan mengobrol dengan kami - apakah Anda pengguna atau pengembang!
Kami bertujuan untuk menjaga komunitas Zulip ramah, ramah dan produktif, jadi jika berpartisipasi, harap hormati norma komunitas kami.
Ini adalah subset dari norma -norma komunitas yang ditautkan di atas, yang lebih relevan bagi pengguna terminal Zulip: mereka yang lebih mungkin berada di lingkungan teks, terbatas dalam baris/kolom karakter, dan hadir dalam aliran yang satu ini lebih kecil ini.
Lebih suka teks dalam blok kode, daripada tangkapan layar
Zulip Terminal mendukung mengunduh gambar, tetapi tidak ada jaminan bahwa pengguna akan dapat melihatnya.
Coba meta + m untuk melihat contoh pemformatan konten, termasuk blok kode
Lebih suka menyebutkan suara secara rutin - atau hindari menyebutkan sepenuhnya
Dengan topik Zulip, penerima yang dituju seringkali sudah bisa jelas. Anggota yang berpengalaman akan hadir sesuai waktu mereka - menanggapi pesan ketika mereka kembali - dan orang lain mungkin dapat membantu sebelum itu.
(Simpan sebutan rutin untuk mereka yang tidak Anda harapkan hadir secara teratur)
Coba ctrl + f / b untuk bersepeda melalui pelengkapan otomatis dalam konten pesan, setelah mengetik @_ untuk menentukan penyebutan diam -diam
Lebih suka memotong kutipan dan balas teks ke bagian yang relevan dari pesan yang lebih panjang - atau hindari mengutip sepenuhnya
Topik Zulip sering membuat pesan mana yang Anda balas. Pesan panjang bisa lebih sulit dibaca dengan baris dan kolom teks terbatas, tetapi ini memburuk jika mengutip seluruh pesan panjang dengan konten tambahan.
Coba > untuk mengutip pesan yang dipilih, menghapus teks seperti biasa saat menyusun pesan
Lebih memilih reaksi emoji cepat untuk menunjukkan perjanjian daripada pesan pendek sederhana
Reaksi mengambil lebih sedikit ruang, termasuk di terminal Zulip, terutama ketika banyak pengguna ingin merespons dengan sentimen yang sama.
Coba + untuk beralih jempol (+1) pada pesan, atau gunakan : untuk mencari reaksi lain
Terminal Zulip sedang dibangun oleh komunitas Zulip yang mengagumkan.
Untuk menjadi bagian dari itu dan berkontribusi pada kode, jangan ragu untuk mengerjakan masalah apa pun atau mengusulkan ide Anda pada #zulip-terminal.
Untuk struktur dan gaya komit, tinjau bagian gaya komit di bawah ini.
Jika Anda baru mengenal git (atau tidak!), Anda dapat mengambil manfaat dari Panduan Zulip Git. Saat berkontribusi, penting untuk dicatat bahwa kami menggunakan alur kerja yang berorientasi rebase .
Tutorial sederhana tersedia untuk mengimplementasikan indikator typing . Ikuti untuk memahami cara menerapkan fitur baru untuk zulip-terminal.
Anda tentu saja dapat menelusuri sumber di GitHub & di pohon sumber yang Anda unduh, dan periksa ikhtisar file sumber untuk ide -ide tentang bagaimana file saat ini diatur.
Terminal Zulip menggunakan URWID untuk membuat komponen UI di terminal. Urwid adalah perpustakaan yang luar biasa di mana Anda dapat membuat terminal UI yang layak hanya menggunakan Python. Tutorial Urwid adalah tempat yang tepat untuk memulai kontributor baru.
Pertama, garpu repositori zulip/zulip-terminal pada github (lihat caranya) dan kemudian klon repositori bercabang Anda secara lokal, mengganti nama Anda dengan nama pengguna gitub Anda:
$ git clone --config pull.rebase [email protected]:YOUR_USERNAME/zulip-terminal.git
Ini harus membuat direktori baru untuk repositori di direktori saat ini, jadi masukkan direktori repositori dengan cd zulip-terminal dan konfigurasikan dan ambil repositori jarak jauh hulu untuk garpu kloning zulip terminal Anda:
$ git remote add -f upstream https://github.com/zulip/zulip-terminal.git
Untuk penjelasan terperinci tentang perintah yang digunakan untuk kloning dan pengaturan ke atas, lihat Langkah 1 dari bagian Kode Get Zulip dari Panduan Git Zulip.
Berbagai opsi tersedia; Kami sedang mengeksplorasi manfaat masing -masing dan akan menghargai umpan balik yang Anda gunakan atau merasa paling berhasil.
Perhatikan bahwa alat yang digunakan dalam setiap kasus biasanya sama, tetapi dipanggil dengan cara yang berbeda.
Perintah berikut harus dijalankan di direktori repositori, dibuat oleh proses yang mirip dengan yang ada di bagian sebelumnya.
$ pip3 install --user pipenv
--python 3.6 untuk lebih spesifik) $ pipenv --three
$ pipenv install --dev
$ pipenv run pip3 install -e '.[dev]'
$ pipenv run gitlint install-hook
Secara manual membuat & mengaktifkan lingkungan virtual; Metode apa pun harus berfungsi, seperti yang digunakan dalam instalasi sederhana di atas
python3 -m venv zt_venv (membuat venv bernama zt_venv di direktori saat ini)source zt_venv/bin/activate (mengaktifkan venv; ini mengasumsikan shell seperti bash)Instal zulip-istilah, dengan persyaratan pengembangan
$ pip3 install -e '.[dev]'
$ gitlint install-hook
Ini adalah pendekatan terbaru dan paling sederhana, jika Anda telah make :
make (mengatur lingkungan virtual yang diinstal di zt_venv di direktori saat ini)source zt_venv/bin/activate (mengaktifkan venv; ini mengasumsikan shell seperti bash)gitlint install-hook (hubungkan kait komitmen gitlint)Setelah Anda mengatur lingkungan pengembangan, Anda mungkin menemukan yang bermanfaat, tergantung pada jenis lingkungan Anda:
| Tugas | Buat & pip | Pipenv |
|---|---|---|
| Jalankan secara normal | zulip-term | pipenv run zulip-term |
| Jalankan dalam mode debug | zulip-term -d | pipenv run zulip-term -d |
| Jalankan dengan profil | zulip-term --profile | pipenv run zulip-term --profile |
| Jalankan semua linter | ./tools/lint-all | pipenv run ./tools/lint-all |
| Jalankan semua tes | pytest | pipenv run pytest |
| Bangun Laporan Cakupan Uji | pytest --cov-report html:cov_html --cov=./ | pipenv run pytest --cov-report html:cov_html --cov=./ |
Jika menggunakan Make With Pip, Running make akan memastikan lingkungan pengembangan mutakhir dengan dependensi yang ditentukan, berguna setelah mengambil dari git dan rebasing.
Pilih editor teks atau lingkungan pengembangan favorit Anda!
Sumber tersebut mencakup file .editorconfig yang memungkinkan banyak editor untuk secara otomatis mengonfigurasi diri mereka sendiri untuk menghasilkan file yang memenuhi persyaratan minimum untuk proyek. Lihat https://editorconfig.org untuk dukungan editor; Perhatikan bahwa beberapa mungkin memerlukan plugin jika Anda ingin menggunakan fitur ini.
Linters dan Tes Otomatis (PyTest) dijalankan secara otomatis dalam CI (Tindakan GitHub) ketika Anda mengirimkan permintaan tarik (PR), atau mendorong perubahan ke permintaan tarik yang ada.
Namun, menjalankan cek ini di komputer Anda dapat mempercepat pengembangan Anda dengan menghindari kebutuhan untuk berulang kali mendorong kode Anda ke GitHub. Perintah untuk mencapai ini tercantum dalam tabel tugas pengembangan di atas (masing -masing linter juga dapat dijalankan melalui skrip dalam tools/ ).
Selain itu, jika menggunakan sistem berbasis make :
make lint dan make test semua kelompok tugasmake check berjalan semua cek, yang berguna sebelum mendorong PR (atau pembaruan)tools/check-branch Akan Berlari make check pada setiap komit di cabang AndaCatatan: Sangat tidak mungkin bahwa permintaan tarik akan digabungkan, sampai semua linter dan tes lulus, termasuk berdasarkan per komit.
Mengoreksi beberapa kesalahan berbaris membutuhkan intervensi manual, seperti dari mypy untuk memeriksa jenis.
Untuk tips tentang pengujian, silakan tinjau bagian lebih lanjut di bawah ini tentang Pytest.
Namun, kesalahan sering lainnya dapat diperbaiki secara otomatis, seperti yang dirinci di bawah ini - ini dapat menghemat banyak waktu secara manual menyesuaikan kode Anda untuk melewati linter!
Jika Anda memiliki masalah memahami mengapa linter atau pytest gagal, silakan dorong kode Anda ke cabang/PR dan kami dapat membahas masalah di PR atau di chat.zulip.org.
Jika Anda memperbarui ini, perhatikan bahwa Anda tidak perlu memperbarui teks di kedua tempat secara manual untuk melewati serat.
Sumber kebenaran ada dalam kode sumber, jadi cukup perbarui file python dan jalankan alat yang relevan. Saat ini kami memiliki:
tools/lint-hotkeys --fix to Regenerate Docs/Hotkeys.md Dari Config/Keys.pytools/lint-docstring --fix to Regenerate Documents/Developer-File-oveview.md dari File Docstrings(Alat -alat ini juga digunakan untuk proses linting, untuk memastikan bahwa file -file ini disinkronkan)
Proyek ini menggunakan black dan isort untuk masing-masing gaya kode dan impor.
Alat -alat ini dapat dijalankan sebagai linters secara lokal, tetapi juga dapat secara otomatis memformat kode Anda untuk Anda.
Jika Anda menggunakan pengaturan berbasis make , Running make fix akan berjalan keduanya (dan beberapa alat lainnya) dan memformat ulang keadaan kode Anda saat ini -jadi Anda ingin berkomitmen terlebih dahulu untuk berjaga -jaga, maka --amend itu berkomitmen jika Anda senang dengan perubahan.
Anda juga dapat menggunakan alat secara individual pada file atau direktori, misalnya. Tes black zulipterminal atau isort tests/model/test_model.py
Saat Anda bekerja secara lokal, menyelidiki perubahan yang harus dilakukan, adalah umum untuk membuat serangkaian komitmen kecil untuk menyimpan kemajuan Anda. Seringkali ini dapat mencakup komitmen yang memperbaiki masalah serat atau pengujian dalam komit sebelumnya. Ini adalah komitmen gaya perkembangan - dan hampir semua orang cenderung menulis komit dalam gaya ini sampai taraf tertentu.
Gaya perkembangan berkomitmen menyimpan perubahan yang baik untuk Anda saat ini. Namun, saat berbagi kode Anda, komit pesan adalah tempat yang tepat untuk mengkomunikasikan kepada orang lain apa yang Anda ubah dan mengapa. Meding struktur juga dapat membuatnya lebih mudah dan lebih cepat bagi pembaca untuk memahami perubahan, dan Anda menghormati waktu mereka. Salah satu contohnya adalah bahwa komitmen tunggal yang sangat besar dapat membutuhkan banyak waktu untuk ditinjau, dibandingkan dengan jika mereka terpecah. Lainnya adalah jika Anda memperbaiki tes/linting dalam komit: komit mana (atau berkomitmen!) Apakah ini diperbaiki, dan jika ada di cabang/PR yang sama, mengapa komit asli tidak diperbaiki saja?
Oleh karena itu, saat membuat permintaan tarik (PR), harap pertimbangkan bahwa kode Anda lebih cenderung digabungkan, lebih cepat, jika lebih mudah dibaca, dipahami, dan ditinjau - dan sebagian besar dari itu adalah cara Anda menyusun perubahan Anda menjadi komit, dan menggambarkan perubahan dalam pesan komit.
Menjadi produktif dan memudahkan PR Anda untuk ditinjau dan diperbarui, kami mengikuti pendekatan yang diambil di Zulip dan di tempat lain, yang bertujuan PRS terdiri dari serangkaian komitmen koheren minimal :
Perhatikan bahwa menjaga prinsip -prinsip ini dapat memberikan manfaat lain, baik sebelum, selama dan setelah meninjau PR, termasuk:
git bisect di cabang Anda atau di main Kami sekarang menegakkan aspek terbatas dari sifat koheren dari komitmen dalam PR dalam pekerjaan sebagai bagian dari Integrasi Berkelanjutan (CI) kami, memastikan PR yang terisolasi , yang pada dasarnya berjalan make check pada setiap komit di cabang Anda. Anda dapat mereplikasi ini secara lokal sebelum mendorong ke GitHub menggunakan tools/check-branch .
Sementara PRS kecil atau bukti konsep pada awalnya baik untuk mendorong sebagaimana adanya, mereka kemungkinan hanya akan ditinjau berdasarkan perubahan keseluruhan. Secara umum jika komit individu terlihat seperti memiliki gaya perkembangan maka pengulas cenderung memberikan umpan balik yang lebih spesifik, dan komit koheren minimal pasti diminta sebelum bergabung.
Perintah Restrukturisasi - Sebagian besar restrukturisasi bergantung pada rebasing interaktif (mis. git rebase -i upstream/main ), tetapi pertimbangkan untuk mencari secara online untuk tindakan tertentu, serta mencari atau bertanya di #Git Help atau #Learning di chat.zulip.org.
Self Review - Pendekatan lain yang berguna adalah meninjau komitmen Anda sendiri baik secara lokal (lihat saran Zulip) dan setelah Anda mendorong ke GitHub. Ini memungkinkan Anda untuk memeriksa dan memperbaiki apa pun yang terlihat tidak pada tempatnya, yang kemungkinan besar akan diambil seseorang dalam ulasan mereka, membantu pengiriman Anda terlihat lebih halus, dan sekali lagi menunjukkan bahwa Anda menghormati waktu pengulas.
Kami bertujuan untuk mengikuti gaya komit standar untuk menjaga git log konsisten dan mudah dibaca.
Sama seperti bekerja dengan kode, kami sarankan Anda merujuk pada komit terbaru di log git, untuk contoh gaya yang kami gunakan secara aktif.
Gaya keseluruhan kami untuk berkomitmen secara luas mengikuti pedoman umum yang diberikan untuk pesan komit zulip, jadi kami sarankan untuk membacanya terlebih dahulu.
Judul komit kami (ringkasan) memiliki sedikit variasi dari gaya zulip umum, dengan masing -masing:
/Tests updated atau Tests added dalam teks komit)refactor: bugfix: dan requirements: (lihat di bawah)Beberapa contoh judul komit: (idealnya lebih deskriptif dalam praktik!)
file3/file1/file2: Improve behavior of something.file1.txt , file2.py dan file3.mdrefactor: file1/file2: Extract some common function.file1.py dan file2.pybugfix: file1: Avoid some noticeable bug.file1.pytests: file1: Improve test for something.file1 , kemungkinan di test_file1.pyrequirements: Upgrade some-dependency from ==9.2 to ==9.3. Untuk membantu dalam memenuhi beberapa aturan ini, Anda dapat menggunakan GitLint , seperti yang dijelaskan di bagian berikut.
Namun , periksa komitmen Anda secara manual versus aturan gaya ini, karena Gitlint tidak dapat memeriksa semuanya - termasuk bahasa atau tata bahasa!
Alat gitlint diinstal secara default di lingkungan pengembangan, dan dapat membantu memastikan bahwa komitmen Anda memenuhi standar yang diharapkan.
Alat ini dapat memeriksa komitmen spesifik secara manual, mis. gitlint untuk komit terbaru, atau gitlint --commits main.. untuk komitmen yang memimpin dari main . Namun, kami sangat merekomendasikan menjalankan gitlint install-hook untuk menginstal kait-message gitlint (atau pipenv run gitlint install-hook dengan Pipenv Setups).
Jika kait diinstal seperti yang dijelaskan di atas, maka setelah menyelesaikan teks untuk komit, itu akan diperiksa oleh Gitlint terhadap gaya yang telah kami atur, dan akan menawarkan saran jika ada masalah pemberitahuan. Jika Gitlint menemukannya, ia akan bertanya apakah Anda ingin berkomitmen dengan pesan sebagaimana adanya ( y untuk 'ya'), hentikan proses komit ( n untuk 'tidak'), atau edit pesan komit ( e untuk 'edit').
Meskipun konten masih tergantung pada keterampilan menulis Anda, ini memastikan struktur pemformatan yang lebih konsisten antara komit, termasuk oleh penulis yang berbeda.
Tes untuk zulip-terminal ditulis menggunakan pytest. Anda dapat membaca tes di folder /tests untuk belajar tentang menulis tes untuk kelas /fungsi baru. Jika Anda baru mengenal Pytest, membaca dokumentasinya pasti direkomendasikan.
Kami saat ini memiliki ribuan tes yang diperiksa setelah menjalankan pytest . Meskipun tergantung pada kemampuan sistem Anda, ini biasanya harus memakan waktu kurang dari satu menit untuk dijalankan. Namun, selama debugging Anda mungkin masih ingin membatasi ruang lingkup tes Anda, untuk meningkatkan waktu penyelesaian:
Jika banyak tes gagal dengan cara yang sangat verbose, Anda dapat mencoba opsi -x (mis. pytest -x ) untuk menghentikan tes setelah kegagalan pertama; Karena parametriisasi tes dan perlengkapan tes, banyak kesalahan/kegagalan yang jelas dapat diselesaikan hanya dengan satu perbaikan! (Coba mis. pytest --maxfail 3 untuk versi yang kurang ketat ini)
Untuk menghindari menjalankan semua tes yang berhasil setiap kali, bersama dengan kegagalan, Anda dapat menjalankan dengan --lf (mis. pytest --lf ), pendek untuk --last-failed (opsi berguna yang serupa mungkin --failed-first dan --new-first , yang dapat bekerja dengan baik dengan -x )
Karena Pytest 3.10 ada --sw ( --stepwise ), yang bekerja melalui kegagalan yang diketahui dengan cara yang sama seperti --lf dan -x dapat digunakan, yang dapat dikombinasikan dengan --stepwise-skip untuk mengontrol tes mana yang merupakan fokus saat ini saat ini
Jika Anda tahu nama tes yang gagal dan/atau di lokasi tertentu, Anda dapat membatasi tes ke lokasi tertentu (mis. pytest tests/model ) atau menggunakan kata kunci yang dipilih (mis. pytest -k __handle )
Ketika hanya sebagian tes yang berjalan, ia menjadi lebih praktis dan berguna untuk menggunakan opsi -v ( --verbose ); alih -alih menunjukkan a . (atau F , E , x , dll) untuk setiap hasil tes, memberikan nama (dengan parameter) dari setiap tes dijalankan (mis. pytest -v -k __handle ). Opsi ini juga menunjukkan lebih banyak detail dalam pengujian dan dapat diberikan beberapa kali (mis. pytest -vv ).
Untuk bantuan tambahan dengan opsi pytest, lihat pytest -h , atau periksa dokumentasi Pytest lengkap.
print STDOUT (output standar) untuk zulip-terminal dialihkan ke ./debug.log jika debugging diaktifkan saat run-time menggunakan -d atau --debug .
Ini berarti bahwa jika Anda ingin memeriksa nilai variabel, atau mungkin menunjukkan mencapai titik tertentu dalam kode, Anda dapat menggunakan print() , mis.
print ( f"Just about to do something with { variable } " ) Dan saat berjalan dengan opsi debugging, string akan dicetak ke ./debug.log .
Dengan terminal seperti bash, Anda dapat menjalankan sesuatu seperti tail -f debug.log di terminal lain, untuk melihat output dari print saat itu terjadi.
Jika Anda ingin men-debug zulip-terminal saat sedang berjalan, atau dalam keadaan tertentu, Anda dapat memasukkan
from pudb . remote import set_trace
set_trace () Di bagian kode yang ingin Anda debug. Ini akan memulai koneksi telnet untuk Anda. Anda dapat menemukan alamat IP dan port koneksi telnet di ./debug.log . Lalu cukup jalankan
$ telnet 127.0.0.1 6899
Di terminal lain, di mana 127.0.0.1 adalah alamat IP dan 6899 adalah port yang Anda temukan di ./debug.log .
Ini kemungkinan berarti bahwa Anda telah menginstal versi normal dan perkembangan zulip-terminal.
Untuk memastikan Anda menjalankan versi pengembangan:
Jika menggunakan PIPENV, hubungi pipenv run zulip-term dari direktori zulip-terminal yang dikloning/diunduh;
Jika menggunakan PIP (PIP3), pastikan Anda telah mengaktifkan lingkungan virtual yang benar (VENV); Bergantung pada bagaimana shell Anda dikonfigurasi, nama VENV mungkin muncul di prompt perintah. Perhatikan bahwa tidak termasuk -e dalam perintah PIP3 juga akan menyebabkan masalah ini.
