Здравствуйте, Dmitriy.
> То есть типа как в консольном варианте дополнение запустить
> невозможно? Т.Е. чтоб не бегать каждый раз в журнал.
NVDA в принципе не консольное приложение, поэтому без GUI многие вещи просто
работать не будут. То есть их чисто в консоли не запустить.
Отладка работы идёт через журнал, подробность сообщений которого можно
настроить.
Вызовы print() в исполняющемся коде дополнения попадают в журнал. Также
можно вставлять вызовы raise, то есть инициировать исключение, которое
остановит исполнение в этой точке и запишет текст в журнал.
> Допустим основной код я напишу с обычным Python, но я ведь могу
> ошибиться в библиотеках NVDA.
Если у вас будет ошибка исполнения, то информацию о ней вы увидите в
журнале.
Если же у вас ошибка в логике работы, то обкладывайте код тестами или
отлаживайте на print'ах, то есть выводя через print() по ходу исполнения
сообщения с технической информацией и таким образом находя этап, на котором
что-то пошло не так.
В принципе, можно запустить NVDA из исходников и получить чуть больше
контроля за процессом исполнения, но это оправдано, если вы куда-то совсем
залезли в ядро NVDA.
Ещё NVDA может быть собрана в бинарном виде в режиме отладки, когда на
разные ошибки на будет явно подавать сигналы.
В принципе, достаточно просто взять какую-нибудь готовую бета-версию,
которая именно так и собрана.
> Можно ли перезапускать только одно дополнение?
В рамках стандартной функциональности NVDA нет.
Чисто теоретически можно написать свой собственный перезагрузчик конкретного
дополнения, почитав реализацию общей перезагрузки в исходниках NVDA. Точка
входа для поиска соответствующего скрипта в файле globalCommands.py, ну а
дальше уже смотреть по коду.
Однако с учётом необходимости в том числе сброса кэша динамически
создаваемых объектов это вряд ли задача, с которой стоит связываться.
Больше похоже на то, что у вас просто не очень эффективно построен рабочий
процесс, и лучше заняться его оптимизацией.
В частности, вызывает некоторые сомнения вся эта история с отладкой на
удалённой машине по NVDA Remote.
> Просто привык к чистому Python, к его консоли и моментальному выводу
> ошибок если таковые есть.
Такое впечатление, что вы занимаетесь разработкой чего-то за рамками
профильной функциональности NVDA.
То, что имеет смысл программировать на уровне дополнения NVDA, по сути в
подавляющем большинстве случаев должно быть так тесно связано со всем
окружением и интерфейсом NVDA, что именно в этом виде это и должно быть
наиболее удобно отлаживать.
Если же у вас просто некое стороннее Python-приложение, просто выдающее
результат своей работы в интерфейс NVDA, ну и всё это планируется запускать
на интерпретаторе Python, встроенном в NVDA, то тут появляются вопросы
оправданности такого архитектурного решения.
В любом случае, если у вас достаточно много кода, который реализует
абстрактную логику, никак не связанную с окружением NVDA, то аккуратно
вынесете его в отдельные модули с нейтральным API, ну и отлаживайте в
обычной консоли Python. Потом уже просто после отладки положите их в
дополнение и импортируете, а в NVDA отладьте только тонкую прослойку
интеграции этих модулей в окружение NVDA.
> Да, и ещё вопрос по отладке. Я сейчас работаю с интернет-базой данных. В
> обычном python я могу посмотреть что подгрузилось в переменные к примеру
> к сорок седьмой строке кода, с помощью команд "next", "step" и так
> далее. могу ли я узнать это в NVDA?
См. выше про уместность написания и запуска приложений общего назначения на
внутреннем Python-интерпретаторе NVDA.
Ну а вообще если запускать NVDA из исходников без компиляции, то возможно у
вас и получится сделать то, что вы хотите, то есть пошагово отладить
Python-код прямо в основном потоке исполнения NVDA.
Инструкцию с перечислением зависимостей и особенностями запуска NVDA из
исходников можно посмотреть в ReadMe её репозитория на GitHub.
Успехов. Никита.
