Отладка Python в Bugsaur¶

Адаптер: debugpy

Поставить адаптер¶

debugpy — модуль Python, поэтому ставится в тот интерпретатор, который выполняет ваш код, то есть обычно в venv проекта, а не в системный питон:

.venv/bin/pip install debugpy

# либо для системного интерпретатора
python3 -m pip install debugpy
python3 -m debugpy --version

Настроить¶

bugsaur init опознаёт проект по pyproject.toml, setup.py или requirements.txt и пишет по профилю на каждую найденную точку входа: main.py, app.py, manage.py, __main__.py в корне и src/<pkg>/__main__.py.

Ещё он ищет .venv/bin/python и venv/bin/python в корне проекта. Если находит, то и адаптер, и отлаживаемый код направляются на этот интерпретатор.

shop/
├── pyproject.toml
├── main.py
├── .venv/bin/python
└── src/shop/__main__.py

version = 1
default = "main"

[profiles.main]
adapter = "debugpy"
adapter_command = "${root}/.venv/bin/python"
program = "main.py"

[profiles.main.launch_arguments]
python = "${root}/.venv/bin/python"

[profiles.shop]
adapter = "debugpy"
adapter_command = "${root}/.venv/bin/python"
program = "src/shop/__main__.py"

[profiles.shop.launch_arguments]
python = "${root}/.venv/bin/python"

Обратите внимание на две отдельные настройки — они не дублируют друг друга:

adapter_command — каким интерпретатором запускается адаптер;
launch_arguments.python — каким интерпретатором выполняется ваш код.

Без виртуального окружения оба откатываются к python3 из PATH, и тогда debugpy должен быть установлен именно в него.

cwd не пишется: рабочим каталогом и так становится корень, а это ровно то, что нужно, чтобы разрешились импорты пакета из src/.

Django¶

[profiles.web]
adapter = "debugpy"
adapter_command = "${root}/.venv/bin/python"
program = "manage.py"
args = ["runserver", "--noreload", "8000"]
env_file = ".env"

--noreload обязателен

Автоперезагрузчик Django поднимает второй процесс, к которому отладчик не прицеплен. Точки останова в перезапущенном воркере не срабатывают, и это выглядит как сломанный отладчик, а не как два процесса.

Отладка модуля вместо файла¶

debugpy принимает module. Штатного поля профиля для него нет, зато работает аварийный выход:

[profiles.tests]
adapter = "debugpy"
program = "."
args = ["-x", "tests/"]

[profiles.tests.launch_arguments]
module = "pytest"

pytest¶

Рецепт выше отлаживает прогон целиком. Чтобы отладить один тест под курсором, профиль не нужен:

bugsaur gui --project . --test-at tests/test_orders.py:24

Bugsaur запускает выбранный pytest-узел через debugpy, наследуя из профиля адаптер, окружение и рабочий каталог. См. Рецепты → Отладка pytest.

Точка входа не в корне и не в `src/`¶

Раскладка вида services/api/app.py определением не находится — профилей ноль, запуск останавливается. Пишется руками:

version = 1
default = "api"

[profiles.api]
adapter = "debugpy"
program = "services/api/app.py"

Диагностика¶

Симптом	Вероятная причина	Куда смотреть
`No module named debugpy`	поставлен не в тот интерпретатор, который запускается	поставьте в venv, проверьте `adapter_command`
В Django точки останова не срабатывают	автоперезагрузчик породил второй процесс	добавьте `--noreload`
`ImportError` для собственного пакета	рабочий каталог не тот, на который рассчитывает код	Рабочий каталог
Останавливается в библиотечном коде, а не в вашем	исключение возникло глубже	Стек вызовов
Сессия не стартует	неверный путь к интерпретатору в `adapter_command`	Адаптер не запускается