zulip terminal
Zulip Terminal 0.7.0
Последние изменения | Конфигурация | Горячие ключи | Часто задаваемые вопросы | Развитие | Учебник
Zulip Terminal является официальным клиентом терминала для Zulip, предоставляя текстовый пользовательский интерфейс (TUI).
Конкретные цели включают:
Узнайте, как использовать терминал Zulip с нашим уроком.
Мы считаем, что клиент уже предоставляет довольно стабильный умеренный опыт повседневного пользователя.
Нынешняя сосредоточена на разработке на улучшение аспектов повседневного использования, которые чаще используются - чтобы уменьшить необходимость того, чтобы пользователи временно переключались на другого клиента для определенной функции.
Текущие ограничения, которые мы ожидаем, только разрешаются в долгосрочной перспективе, включают поддержку:
Клиент терминала в настоящее время имеет ряд преднамеренных различий в веб -клиенте Zulip:
Для запросов о отсутствующей поддержке функций, пожалуйста, посмотрите на часто задаваемые вопросы (часто задаваемые вопросы), наши открытые проблемы или общаться с пользователями и разработчиками онлайн на сервере Zulip Community!
Мы рекомендуем установить в выделенной виртуальной среде Python (см. Ниже) или использовать автоматизированную опцию, такую как PIPX
Стабильные выпуски - они доступны на PYPI в качестве пакета ZULIP -термина
Для установки запустите команду, такую как: pip3 install zulip-term
Последние версии (GIT) - последняя версия разработки может быть установлена из main филиала репозитория GIT
Для установки запустите команду, такую как: pip3 install git+https://github.com/zulip/zulip-terminal.git@main
Мы также предоставляем несколько образцов Dockerfiles для создания изображений Docker в Docker/.
С Python 3.6+, необходимым для запуска, следующее должно работать над большинством систем:
python3 -m venv zt_venv (создает виртуальную среду с именем zt_venv в текущем каталоге)source zt_venv/bin/activate (активирует виртуальную среду; это предполагает, как Bash-подобная оболочка) Если вы откроете другое окно терминала (или отключить/перезапустить свой компьютер), вам нужно снова запустить шаг 2 вышеуказанного списка, прежде чем запустить zulip-term , поскольку это активирует эту виртуальную среду. Вы можете прочитать больше о виртуальных средах в документации Python 3 Venv.
Обратите внимание, что нет системы автоматического обновления, поэтому, пожалуйста, отслеживайте места обновления, относящиеся к вашей установке версии:
Стабильные выпуски
Перед обновлением мы рекомендуем проверить изменения в последних выпусках, чтобы вы знали о каких -либо важных изменениях между выпусками.
В настоящее время они объявлены в теме Terminal Lelease Temons Lelease на сервере сообщества Zulip (https://chat.zulip.org), который виден без учетной записи.
Если вы хотите получать электронные письма при объявлении обновлений, вы можете подписаться на учетную запись на этом сервере, которая позволит вам включить уведомления по электронной почте для потока #AnnOnc
Вы также можете настроить настройку часов GitHub на странице проекта, чтобы включить выпуски.
PYPI предоставляет канал RSS -выпуска, и различные другие услуги отслеживают эту информацию.
Последние (GIT) версии
Версии, установленные из main ветви GIT, также не будут автоматически обновляться - «последнее» относится к состоянию в точке установки.
Это также относится к другим установкам источника или разработки (например, https://aur.archlinux.org/packages/python-zulip-tmer-git/).
Следовательно, обновите свой пакет, используя вышеуказанную команду, или один, относящийся к вашей системе пакетов (например, Arch).
Несмотря на то, что main филиала предназначена для того, чтобы оставаться стабильной, при обновлении между двумя произвольными «последними» версиями, пожалуйста, имейте в виду, что изменения не обобщены , хотя наш журнал коммит должен быть очень читаемым.
После первого запуска zulip-term он ищет файл zuliprc по умолчанию в вашем домашнем каталоге, который содержит детали для входа в Zulip-сервер.
Если он не найдет этот файл, у вас есть два варианта:
zulip-term предложит вам для вашего сервера, электронной почты и пароля и создаст для вас файл zuliprc в этом месте
Примечание. Если вы используете Google, Github или другую внешнюю аутентификацию для доступа к вашей организации Zulip, то, вероятно, у вас не будет установленного пароля, и в настоящее время необходимо создать один для использования Zulip-Terminal.
<Zulip server URL>/accounts/password/reset/ для создания нового пароля для вашей учетной записи (например: https://chat.zulip.org/accounts/password/reset/). Каждый раз, когда вы запускаете zulip-term , вы можете указать путь к альтернативному файлу zuliprc , используя параметры -c или --config-file , например. $ zulip-term -c /path/to/zuliprc
Файл .zuliprc , соответствующий вашей учетной записи на конкретном сервере Zulip, может быть загружен с помощью веб -или настольных приложений, подключенных к этому серверу. В недавних версиях это можно найти в ваших личных настройках в разделе учетной записи и конфиденциальности , в соответствии с ключом API как «Показать/изменить свой ключ API».
Если это ваша единственная учетная запись Zulip, вы можете переместить и переименовать этот файл в местоположение файла по умолчанию выше или переименовать его в нечто более запоминающееся, которое вы можете передать в опцию ---config-file . Этот файл .zuliprc дает вам все разрешения, которые у вас есть в качестве пользователя.
Аналогичные .zuliprc files могут быть загружены из раздела ботов для любых ботов, которые вы настраивали, хотя с соответственно ограниченными разрешениями.
ПРИМЕЧАНИЕ. Если ваш сервер использует самозавешенные сертификаты или небезопасное соединение, вам нужно будет добавить дополнительные параметры в файл zuliprc вручную - см. Документацию для модуля Zulip Python.
Мы предлагаем запустить zulip-term используя опцию -e или --explore (в режиме исследования), когда вы впервые пробуете Zulip Terminal, где мы намеренно не отмечаем сообщения как чтение. Попробуйте следить за нашим учебником, чтобы понять вещи.
Файл zuliprc содержит два раздела:
[api] с информацией, необходимой для подключения к вашему ZULIP -серверу[zterm] с конфигурацией, специфичной для zulip-term Файл с только первым разделом может быть автоматически сгенерирован в некоторых случаях с помощью zulip-term , или вы можете загрузить один из своей учетной записи на вашей сервере (см. Выше). Части второго раздела могут быть добавлены и скорректированы поэтапно, когда вы хотите настроить поведение zulip-term .
Приведенный ниже пример, с содержимым фиктивного [api] , представляет собой рабочий файл конфигурации со всеми совместимыми значениями [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.
Следующая команда устанавливает notify-send в системах на основе Debian, аналогичные команды можно найти и для других систем Linux.
sudo apt-get install libnotify-bin
Не требуется дополнительного пакета, чтобы включить уведомления в OS X. Однако для того, чтобы иметь звук уведомления, установите следующую переменную (на основе вашего типа оболочки). Значение звука (здесь Ping) может быть любым из файлов .aiff , найденных по адресу /System/Library/Sounds или ~/Library/Sounds .
Избиение
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.bash_profile
source ~/.bash_profile
Zsh
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.zshenv
source ~/.zshenv
Zulip Terminal позволяет пользователям копировать определенные тексты в буфер обмена через модуль Python Pyperclip . Этот модуль использует различные системные пакеты, которые могут или не могут поступать с ОС. Функция «Скопировать в буфер обмена» в настоящее время доступна только для копирования потоковой электронной почты из всплывающего окна информации о потоке.
На Linux этот модуль использует команды xclip или xsel , которые уже должны поставляться с ОС. Если ни одна из этих команд не установлена в вашей системе, установите кого -либо, используя:
sudo apt-get install xclip [Recommended]
ИЛИ
sudo apt-get install xsel
Для включения копирования в буфер обмена в буфер обмена не требуется дополнительная упаковка.
В то время как Zulip Terminal предназначен для работы с любым сервером ZULIP, основные участники присутствуют на сервере сообщества Zulip по адресу https://chat.zulip.org, с большинством разговоров в потоке #Zulip-концевого .
Вы можете просмотреть разговоры в этом потоке, используя ссылку выше, или подписаться на учетную запись и общаться с нами - будь то пользователь или разработчик!
Мы стремимся поддерживать общественное сообщество, гостеприимно и продуктивно, поэтому, если участвовать, пожалуйста, уважайте наши нормы сообщества.
Это подмножество норм сообщества , связанных выше, которые более актуальны для пользователей терминала Zulip: те, которые с большей вероятностью находятся в текстовой среде, ограниченной в рядах/столбцах символов и присутствуют в этом меньшем потоке.
Предпочитаю текст в кодовых блоках вместо скриншотов
Зулип -терминал поддерживает загрузку изображений, но нет никакой гарантии, что пользователи смогут их просматривать.
Попробуйте Meta + M , чтобы увидеть форматирование примера контента, включая кодовые блоки
Предпочитают безмолвные упоминания из -за регулярных упоминаний - или полностью избегайте упоминаний
С темами Зулипа, предполагаемый получатель часто может быть ясным. Опытные участники будут присутствовать по мере разрешения времени - отвечать на сообщения, когда они возвращаются - и другие могут помочь до этого.
(Сохраните регулярные упоминания для тех, кого вы не ожидаете регулярно присутствовать)
Попробуйте Ctrl + F / B , чтобы пройти велосипед через автозаполнение в содержимовом сообщении после ввода @_ , чтобы указать молчаливое упоминание
Предпочитаю обрезку и ответьте текст только на соответствующие части более длинных сообщений - или избегать цитирования полностью
Темы Зулипа часто дают понять, на какое сообщение вы отвечаете. Длинные сообщения могут быть сложнее читать с ограниченными строками и столбцами текста, но это ухудшается, если они цитируют все длинное сообщение с дополнительным контентом.
Попробуйте > процитировать выбранное сообщение, удаляя текст как обычно при составлении сообщения
Предпочитаю быстрой реакции эмодзи, чтобы показать согласие вместо простых коротких сообщений
Реакции занимают меньше места, в том числе в терминале Zulip, особенно когда несколько пользователей хотят ответить одинаковым чувством.
Попробуйте + переключить палец вверх (+1) в сообщении или использовать : для поиска других реакций
Зулип -терминал строится удивительным сообществом зулипа.
Чтобы быть его частью и внести свой вклад в код, не стесняйтесь работать над любой проблемой или предложить свою идею на #Zulip-Terminal.
Для структуры коммита и стиля, пожалуйста, просмотрите раздел стиля коммита ниже.
Если вы новичок в git (или нет!), Вы можете извлечь выгоду из руководства Zulip GIT. При участии важно отметить, что мы используем рабочий процесс, ориентированный на Rebase .
Простой учебник доступен для реализации индикатора typing . Следите за ним, чтобы понять, как реализовать новую функцию для ZULIP-терминала.
Конечно, вы можете просмотреть источник на GitHub и в дереве источника, которое вы загружаете, и проверить обзор исходного файла для представлений о том, как в настоящее время расположены файлы.
Zulip Terminal использует Urwid для визуализации компонентов пользовательского интерфейса в терминале. Урвид - это потрясающая библиотека, с помощью которой вы можете отображать приличный терминальный пользовательский интерфейс, просто используя Python. Учебное пособие Урвида - отличное место для начала для новых участников.
Во-первых, разветвляется репозиторий zulip/zulip-terminal на GitHub (см. Как), а затем клонировать свое раздвоенное хранилище локально, заменив your_username своим именем пользователя GitHub:
$ git clone --config pull.rebase [email protected]:YOUR_USERNAME/zulip-terminal.git
Это должно создать новый каталог для репозитория в текущем каталоге, поэтому введите каталог хранилища с помощью cd zulip-terminal и настроить и принести вверх по течению удаленный репозиторий для вашей клонированной вилки Zulip Terminal:
$ git remote add -f upstream https://github.com/zulip/zulip-terminal.git
Для получения подробного объяснения команд, используемых для клонирования и настройки вверх по течению, см. Шаг 1 раздела Get Zulip Code в Руководстве ZULIP GIT.
Различные варианты доступны; Мы исследуем преимущества каждого из них и будем признательны от обратной связи, которую вы используете или чувствуете, что работает лучше всего.
Обратите внимание, что инструменты, используемые в каждом случае, обычно одинаковы, но вызываются по -разному.
Следующие команды должны выполняться в каталоге репозитория, созданный процессом, аналогичным процессу в предыдущем разделе.
$ 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 (создает venv с именем zt_venv в текущем каталоге)source zt_venv/bin/activate (активирует VENV; это предполагает, как Bash-подобная оболочка)Установите ZULIP-термин с требованиями к разработке
$ pip3 install -e '.[dev]'
$ gitlint install-hook
Это самый новый и самый простой подход, если вы make :
make (устанавливает установленную виртуальную среду в zt_venv в текущем каталоге)source zt_venv/bin/activate (активирует VENV; это предполагает, как Bash-подобная оболочка)gitlint install-hook (подключите крюк Gitlint Commit-Message)После установки среды разработки, вы можете найти следующее полезное, в зависимости от вашего типа среды:
| Задача | 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=./ |
При использовании Make with Pip make будет гарантировать, что среда разработки актуальна с указанными зависимостями, полезными после извлечения из GIT и переживания.
Выберите свой любимый текстовый редактор или среду разработки!
Источник включает в себя файл .editorconfig , который позволяет многим редакторам автоматически настраивать себя для создания файлов, которые соответствуют минимальным требованиям для проекта. См. Https://editorconfig.org для поддержки редактора; Обратите внимание, что некоторые могут потребовать плагинов, если вы хотите использовать эту функцию.
Линтеры и автоматические тесты (Pytest) автоматически работают в CI (Github Dazes) при отправке запроса на вытяжение (PR) или вносите изменения в существующий запрос на вытягивание.
Тем не менее, запуск этих проверок на вашем компьютере может ускорить вашу разработку, избегая необходимости многократно подталкивать ваш код на GitHub. Команды для достижения этого перечислены в приведенной выше таблице задач разработки (отдельные линщики также могут выполняться с помощью сценариев в tools/ ).
Кроме того, при использовании системы на основе make :
make lint и make test запустить всю каждую группу задачmake check запуска все чеки, что полезно перед нажатием PR (или обновления)tools/check-branch пробегают make check в каждом коммите в вашем филиалеПримечание. Маловероятно, что запрос на тягу будет объединен, пока не пройдут все линтеры и тесты, в том числе для каждого участия.
Исправление некоторых ошибок в снятии требует ручного вмешательства, например, от mypy для проверки типов.
Для получения советов по тестированию, пожалуйста, ознакомьтесь с разделом ниже, касающимся Pytest.
Тем не менее, другие ошибки вкладки могут быть исправлены автоматически, как подробно описано ниже - это может сэкономить много времени вручную, настраивая ваш код для прохождения Linters!
Если у вас есть проблемы с пониманием того, почему Linters или Pytest терпят неудачу, пожалуйста, перейдите к вашему коду в филиал/PR, и мы можем обсудить проблемы в PR или на чате. Zulip.org.
Если вы обновите их, обратите внимание, что вам не нужно обновлять текст в обоих местах вручную для прохождения линии.
Источник истины находится в исходном коде, поэтому просто обновите файл Python и запустите соответствующий инструмент. В настоящее время у нас есть:
tools/lint-hotkeys --fix для регенерации документов/hotkeys.md из config/keys.pytools/lint-docstring --fix для регенерации документов/разработчиков-file-overview.md из файла docstrings(Эти инструменты также используются для процесса сжима, чтобы гарантировать, что эти файлы синхронизированы)
Проект использует black и isort для кодового стиля и сортировки импорта соответственно.
Эти инструменты могут быть запускаются как локально, но также могут автоматически форматировать ваш код для вас.
Если вы используете установку на основе make , запуск make fix будет запускать оба (и несколько других инструментов) и --amend текущего состояния вашего кода -так что вы захотите сначала совершить на всякий случай, а затем, если вы довольны изменениями.
Вы также можете использовать инструменты индивидуально в файле или каталоге, например. black zulipterminal или isort tests/model/test_model.py
Работая на местном уровне, исследуя изменения для внесения, обычно можно сделать серию небольших коммитов для хранения ваших успехов. Часто это может включать в себя коммиты, которые исправляют проблемы с личинкой или тестированием в предыдущем коммите. Это коммиты в стиле развития - и почти все, вероятно, в некоторой степени будут писать коммиты в этом стиле.
Коммиты в стиле развития хранят изменения для вас прямо сейчас. Однако, обмениваясь вашим кодом, сообщения о коммутете - отличное место, чтобы вместо этого сообщить другим, что вы меняете и почему. Прилив структура также может упростить и быстрее для читателя, чтобы понять изменения, и что вы уважаете их время. Одним из примеров является то, что очень большие коммиты могут занять много времени, по сравнению с тем, если они разделены. Другое, если вы исправляете тесты/лининг в коммите: какой коммит (или коммиты!) Это исправляет, и если он находится в том же ветви/PR, почему первоначальный коммит не просто не исправит вместо этого?
Поэтому при создании запроса на притяжение (PR), пожалуйста, учтите, что ваш код , скорее всего, будет объединен, быстрее, если его легче читать, понимать и просмотреть - и большая часть этого заключается в том, как вы структурируете свои изменения в коммиты и описываете эти изменения в сообщениях о коммите.
Чтобы быть продуктивным и облегчить рассмотрение и обновление ваших PRS, мы следуем подходу, используемому в Зулип и в других местах, стремясь к PRS, чтобы состоять из ряда минимальных последовательных коммитов:
Обратите внимание, что сохранение этих принципов может дать другие преимущества, как до, так и после рассмотрения PR, включая:
git bisect в вашей филиале или на main Теперь мы обеспечиваем ограниченный аспект согласованного характера коммитов в PR на работе в рамках нашей непрерывной интеграции (CI), обеспечивая изолированные PR Commits , которые, по сути, проводят make check на каждом коммите в вашем филиале. Вы можете воспроизвести это локально перед тем, как отправиться в GitHub, используя tools/check-branch .
В то время как небольшие или доказательство концепции PRS изначально подходит для продвижения, как они есть, они, вероятно, будут рассмотрены только на основе общих изменений. Как правило, если отдельные коммиты выглядят так, как будто они имеют стиль развития, то рецензенты могут дать менее конкретную обратную связь, а минимальные когерентные коммиты наверняка будут запрашивать перед слиянием.
Команды реструктуризации - большинство реструктуризации опирается на интерактивное перебазирование (например, git rebase -i upstream/main ), но рассмотрите возможность поиска в Интернете для конкретных действий, а также поиск или просьба в #git help или #Learning на чате.zulip.org.
Самостоятельная проверка - Еще один полезный подход - это просмотреть свои собственные коммиты как на местном уровне (см. Предложения Zulip), так и после того, как вы подталкиваете к GitHub. Это позволяет вам осмотреть и исправлять все, что выглядит неуместно, что кто -то, вероятно, подхватит в своем обзоре, помогая вашим представлениям выглядеть более отточенным, а также снова указывая на то, что вы уважаете время рецензентов.
Мы стремимся следовать стандартному стилю коммита, чтобы поддерживать постоянный git log и простых в чтении.
Подобно работе с кодом, мы предлагаем вам обратиться к недавним коммитам в журнале GIT, для примеров стиля, который мы активно используем.
Наш общий стиль для сообщений о коммите в целом соответствует общим руководящим принципам, приведенным для сообщений Zulip Commit, поэтому мы рекомендуем прочитать это в первую очередь.
Наши названия коммит (резюме) имеют небольшие изменения от общего стиля зулипа, с каждым:
/Tests updated или Tests added в текст коммита)refactor: bugfix: и requirements: (см. Ниже)Некоторый пример Commit названия: (в идеале более описательный на практике!)
file3/file1/file2: Improve behavior of something.file1.txt , file2.py и file3.mdrefactor: file1/file2: Extract some common function.file1.py и file2.pybugfix: file1: Avoid some noticeable bug.file1.pytests: file1: Improve test for something.file1 , вероятно, в test_file1.pyrequirements: Upgrade some-dependency from ==9.2 to ==9.3. Чтобы помочь удовлетворить некоторые из этих правил, вы можете использовать GitLint , как описано в следующем разделе.
Тем не менее , пожалуйста, проверьте свои коммиты вручную против этих правил стиля, поскольку Gitlint не может проверить все - включая язык или грамматику!
Инструмент gitlint устанавливается по умолчанию в среде разработки и может помочь обеспечить, чтобы ваши коммиты соответствовали ожидаемому стандарту.
Инструмент может проверить конкретные коммиты вручную, например. gitlint для последнего коммита, или gitlint --commits main.. для коммитов, ведущих из main . Тем не менее, мы настоятельно рекомендуем запустить gitlint install-hook , чтобы установить крюк gitlint Commite-Message (или pipenv run gitlint install-hook с установками Pipenv).
Если крюк установлен, как описано выше, то после завершения текста для коммита, он будет проверять Gitlint против стиля, который мы настроили, и предложит советы, если есть какие -либо проблемы, которые он замечает. Если Gitlint найдет что -либо, он спросит, хотите ли вы совершить с сообщением как есть ( y для «да»), остановите процесс коммита ( n для «нет») или отредактируйте сообщение о коммите ( e для «редактирования»).
Хотя контент по -прежнему зависит от ваших навыков письма, это обеспечивает более последовательную структуру форматирования между коммитами, в том числе разными авторами.
Тесты для ZULIP-терминала написаны с использованием Pytest. Вы можете прочитать тесты в папке /tests чтобы узнать о написании тестов для нового класса /функции. Если вы новичок в Pytest, чтение его документации определенно рекомендуется.
В настоящее время у нас есть тысячи тестов, которые проверяются при запуске pytest . Несмотря на то, что это зависит от возможности вашей системы, это обычно должно запускать менее одной минуты. Однако во время отладки вы все равно можете ограничить объем ваших тестов, чтобы улучшить время выполнения выполнения:
Если множество тестов провалится очень многословно, вы можете попробовать опцию -x (например, pytest -x ), чтобы остановить тесты после первого сбоя; Из -за параметризации тестов и тестовых приспособлений многие очевидные ошибки/сбои могут быть разрешены только одним исправлением! (Попробуйте, например, pytest --maxfail 3 для менее строгих версий этого)
Чтобы не запустить все успешные тесты каждый раз, наряду с неудачами, вы можете запустить с --lf (например, pytest --lf ), коротко для --last-failed (аналогичные полезные варианты могут быть --failed-first и --new-first , которые могут хорошо работать с -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 STDOUT (стандартный выход) для ZULIP-терминала перенаправляется на ./debug.log , если отладка включена во время выполнения с использованием -d или --debug .
Это означает, что если вы хотите проверить значение переменной или, возможно, указывать на достижение определенной точки в коде, вы можете просто использовать print() , например.
print ( f"Just about to do something with { variable } " ) А при запуске с вариантом отладки строка будет напечатана на ./debug.log .
С помощью терминала, подобного Bash, вы можете запустить что -то вроде tail -f debug.log в другом терминале, чтобы увидеть выход из print , как это происходит.
Если вы хотите отладить ZULIP-конце
from pudb . remote import set_trace
set_trace () В той части кода вы хотите отладить. Это запустит подключение к Telnet для вас. Вы можете найти IP -адрес и порт соединения Telnet в ./debug.log . Тогда просто беги
$ telnet 127.0.0.1 6899
В другом терминале, где 127.0.0.1 является IP -адресом, а 6899 - порт, который вы найдете в ./debug.log .
Это, вероятно, означает, что вы установили как нормальные, так и разработки версии ZuLip-терминала.
Чтобы убедиться, что вы запустите версию разработки:
При использовании Pipenv вызовите pipenv run zulip-term из клонированного/загруженного zulip-terminal каталога;
При использовании PIP (PIP3) убедитесь, что вы активировали правильную виртуальную среду (VENV); В зависимости от того, как настроена ваша оболочка, имя Venv может отображаться в командной строке. Обратите внимание, что не включая -e в команде PIP3 также вызовет эту проблему.
