PyCharm — самая удобная, на мой взгляд, IDE для Python'a от авторов великолепного PhpStorm. В отличие от средства разработки на PHP, имеет бесплатную версию с несколько урезанным функционалом, в частности без шикарного модуля для запуска и отладки скриптов на удаленном сервере. Тем не менее, стандартных возможностей хватает и для создания настольных windows-приложений, и для скриптинга, и для серверного кода.
Критичной эта особенность стала в тот момент, когда мне захотелось писать скрипты на ПК и получать результат их выполнения на Raspberry Pi без копирования и запуска вручную. Дальше мой рецепт для Windows 8.1 (только запуск).
Да, пойдем по сложному пути и используем в качестве рабочего места машину с запущенным Windows. Провернуть подобное на Linux было бы проще, но я решил заодно посмотреть возможности нового для меня Windows PowerShell вместо bash'a. Удивительно, но он справился. Так же можно использовать cmd.exe и bat-файлы.
Итак, железо — Raspberry Pi любой модели с raspbian на борту, доступом к локальной сети и работающим ssh. ПК с окнами подключен в эту же сеть, на нем уже установлены PyCharm и Python (на момент написания, актуальная версия в репозиториях Raspbian — 3.2, лучше установить такую же).
ОС от Microsoft не имеет штатных ssh-клиентов, так что ставим на нее что-то удобное вроде Xshell: www.netsarang.com/download/down_xsh.html. Также мне понадобились утилиты для командной строки от putty: pscp и plink: www.chiark.greenend.org.uk/~sgtatham/putty/download.html. Кстати, сама pytty тоже достаточно удобна.
Я буду выполнять скрипты от имени root. Нельзя так делать.
Включаем клиент (Xshell), подключаемся к raspberry, ставим
Для начала создадим фейковый интерпретатор. Запускаем Windows PowerShell от имени администратора, создаем папочку.
Чтобы не потерять и не мусорить в PATH, закидываем сюда же pscp и plink:
PyCharm принимает в качестве исполняющегося файла интерпретатора только файлы с именем python.exe, так что сделаем такую нехорошую вещь:
Вероятно, придется отключить проверки подписи скриптов:
Создаем файл скрипта для загрузки проекта на сервер, например такой (пусть зовется deploy.ps1):
Где 192.168.1.230 — адрес удаленного сервера, root и passw0rd — логин и пароль. На один раз хватит и хардкода.
Эта версия принимает адрес до локальной папки и имя папки, которую требуется создать на сервере, и просто копирует все содержимое из первой во вторую. Для проектов больше сотни килобайт стоит оптимизировать это место.
Создаем файл передачи и запуска кода на сервере (пусть python.ps1). В простейшем случае такой:
Где testProject — название будущего проекта.
Сделаем так, чтоб вместо интерпретатора пайтона запускался интерпретатор оболочки.
Создав проект, заходим в настройки File->Settings или Ctrl-Alt-S. В вкладке проекта — Project Interpreter. Нажимаем Add Local:
Добавляем:
IDE ругается, но добавляет в список. Нажмем «More..» и переименуем в wrapper:
Лучше вернуть Project Interpreter обратно на версию 3.2 (у меня стоит 3.4), иначе отвалятся подсказки и автодополнение.
Здесь всё, откроем конфигурации запуска Run->Edit Configurations. И добавим два конфига:
— Обычный для локальной отладки:
— И нашего монстра для удаленного запуска:
Где выбираем в качестве интерпретатора наш wrapper и задаем постоянный параметр — путь до файла python.ps1. Таким образом на самом деле будет вызван powershell, который выполнит переданный ему скрипт python.ps1 с передачей всех последующих параметров.
Сейчас уже можно написать Hello World и выполнить на целевой машине, но в таком виде мы сможем тестировать только проекты из одного файла. Для выгрузки на сервер всего проекта добавим здесь же внешний инструмент.
Все. Теперь при выбранной конфигурации remote после нажатия кнопки Run проект зальется на удаленный сервер, где будет запущен скрипт main.py, stdout которого будет выводиться обратно в консоль pycharm.
Для некоторой гибкости и удобства настройки можно добавить генерацию скрипта python.ps1 с использованием имени проекта, а данные об удаленном хосте перенести в одно место
deploy.ps1
Теперь для настройки под новый сервер надо будет поменять только три строки, а при создании нового проекта — добавить в него конфигурацию remote.
Критичной эта особенность стала в тот момент, когда мне захотелось писать скрипты на ПК и получать результат их выполнения на Raspberry Pi без копирования и запуска вручную. Дальше мой рецепт для Windows 8.1 (только запуск).
Да, пойдем по сложному пути и используем в качестве рабочего места машину с запущенным Windows. Провернуть подобное на Linux было бы проще, но я решил заодно посмотреть возможности нового для меня Windows PowerShell вместо bash'a. Удивительно, но он справился. Так же можно использовать cmd.exe и bat-файлы.
Итак, железо — Raspberry Pi любой модели с raspbian на борту, доступом к локальной сети и работающим ssh. ПК с окнами подключен в эту же сеть, на нем уже установлены PyCharm и Python (на момент написания, актуальная версия в репозиториях Raspbian — 3.2, лучше установить такую же).
Коммуникации
ОС от Microsoft не имеет штатных ssh-клиентов, так что ставим на нее что-то удобное вроде Xshell: www.netsarang.com/download/down_xsh.html. Также мне понадобились утилиты для командной строки от putty: pscp и plink: www.chiark.greenend.org.uk/~sgtatham/putty/download.html. Кстати, сама pytty тоже достаточно удобна.
Python на плате
Я буду выполнять скрипты от имени root. Нельзя так делать.
Включаем клиент (Xshell), подключаемся к raspberry, ставим
apt-get install python3
«Поддельный» интерпретатор
Для начала создадим фейковый интерпретатор. Запускаем Windows PowerShell от имени администратора, создаем папочку.
cd mkdir PythonWrapper
cd PythonWrapper
Чтобы не потерять и не мусорить в PATH, закидываем сюда же pscp и plink:
cp ~\Downloads\plink.exe .
cp ~\Downloads\pscp.exe .
PyCharm принимает в качестве исполняющегося файла интерпретатора только файлы с именем python.exe, так что сделаем такую нехорошую вещь:
PS C:\PythonWrapper> cmd.exe /c mklink python.exe C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
символическая ссылка создана для python.exe <<===>> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Вероятно, придется отключить проверки подписи скриптов:
Set-ExecutionPolicy Unrestricted
Создаем файл скрипта для загрузки проекта на сервер, например такой (пусть зовется deploy.ps1):
C:\PythonWrapper\plink -ssh root@192.168.1.230 -pw passw0rd 'rm -rf '$args[1]';mkdir -p '$args[1]
$dpath = 'root@192.168.1.230:~/' + $args[1] + '/'
C:\PythonWrapper\pscp -r -scp -pw passw0rd $args[0] $dpath
Где 192.168.1.230 — адрес удаленного сервера, root и passw0rd — логин и пароль. На один раз хватит и хардкода.
Эта версия принимает адрес до локальной папки и имя папки, которую требуется создать на сервере, и просто копирует все содержимое из первой во вторую. Для проектов больше сотни килобайт стоит оптимизировать это место.
Создаем файл передачи и запуска кода на сервере (пусть python.ps1). В простейшем случае такой:
cat $args[0] | C:\PythonWrapper\plink -ssh root@192.168.1.230 -pw passw0rd 'cd testProject/testProject;python3 -'
Где testProject — название будущего проекта.
Настройка IDE
Сделаем так, чтоб вместо интерпретатора пайтона запускался интерпретатор оболочки.
Создав проект, заходим в настройки File->Settings или Ctrl-Alt-S. В вкладке проекта — Project Interpreter. Нажимаем Add Local:
Добавляем:
IDE ругается, но добавляет в список. Нажмем «More..» и переименуем в wrapper:
Лучше вернуть Project Interpreter обратно на версию 3.2 (у меня стоит 3.4), иначе отвалятся подсказки и автодополнение.
Здесь всё, откроем конфигурации запуска Run->Edit Configurations. И добавим два конфига:
— Обычный для локальной отладки:
— И нашего монстра для удаленного запуска:
Где выбираем в качестве интерпретатора наш wrapper и задаем постоянный параметр — путь до файла python.ps1. Таким образом на самом деле будет вызван powershell, который выполнит переданный ему скрипт python.ps1 с передачей всех последующих параметров.
Сейчас уже можно написать Hello World и выполнить на целевой машине, но в таком виде мы сможем тестировать только проекты из одного файла. Для выгрузки на сервер всего проекта добавим здесь же внешний инструмент.
Все. Теперь при выбранной конфигурации remote после нажатия кнопки Run проект зальется на удаленный сервер, где будет запущен скрипт main.py, stdout которого будет выводиться обратно в консоль pycharm.
Улучшение
Для некоторой гибкости и удобства настройки можно добавить генерацию скрипта python.ps1 с использованием имени проекта, а данные об удаленном хосте перенести в одно место
deploy.ps1
$dhost = '192.168.1.230'
$password = 'passw0rd'
$login = 'root'
"cat `$args[0] | C:\PythonWrapper\plink -ssh $($login)@$($dhost) -pw $($password) 'cd {0}/{0};python3 -'" -f $args[1]> .\python.ps1
$duser = $login + '@' + $dhost
.\plink -ssh $duser -pw $password 'rm -rf '$args[1]';mkdir -p '$args[1]
$dpath = $duser + ':~/' + $args[1] + '/'
.\pscp -r -scp -pw $password $args[0] $dpath
Теперь для настройки под новый сервер надо будет поменять только три строки, а при создании нового проекта — добавить в него конфигурацию remote.
Комментарии (6)
PositiveAlex
26.04.2015 02:14можно ведь прямо в ide написать скрипт для ansible, которая будет автоматом загружать другой скрипт по ssh куда угодно. для дебага это не удобно, конечно, но для получения результатов вполне сойдёт. хотя вариант с stdout через ансибл я не изучал.
jgc128
Есть еще такая классная штука как Python Tools For Visual Studio — она поддерживает даже точки останова в удаленных скриптах!
pytools.codeplex.com/wikipage?title=Features%20Remote%20Debugging
int19h
А кто-то не поддерживает точки останова при удаленной отладке?
Кстати, с запуском у нас такие же заморочки. В смысле, что нужно городить огород с костылями вроде этого. Единственное что, бинарь не обязан называться python.exe. В идеале, конечно, надо бы прикрутить удаленный запуск напрямую через SSH — это есть в списке фич.
Впрочем, что касается конкретно Raspberry Pi, Win10 и PTVS — подождите Build через неделю, там будет кое-что :)
jgc128
Решение, предложенное в статье — нет :)
О, будет здорово!
Будем ждать)
int19h
>> Решение, предложенное в статье — нет :)
Хм. Это, видимо, из-за несоответствия локальных путей удаленным. Но обычно во всех средах, где удаленная отладка предусмотрена из коробки (в PyCharm это через pydevd), есть какой-то способ задать соответствие путей. Либо явно, как в PyDev, либо отладчик хитрым способом пытается отмапить пути, как у PTVS (мы ходим по удаленной файловой системе и ищем __init__.py, чтобы реконструировать часть пути, которая относится к имени модуля, а потом сравниваем только эту часть с локальным именем файла). В PyCharm, судя по докам, есть явный path mapping — почему нельзя использовать его?
jgc128
Так в том и дело, что PyCharm в бесплатной версии не имеет возможности удаленной отладки.