Настройка удаленного интерпретатора на Pycharm для Django


В этой статье хочу рассказать, а также показать настройку полезного инструмента для удаленной разработки от компании JetBrains встроенное в IDE Pycharm. Такой инструмент есть уже давно, но многие разработчики относятся к этому не серьезно, и для внесения изменений в проект предпочитают разворачивать его локально. Когда намного легче на том-же сервере, сделать копию части проекта и изменять или тестировать на другом порту с помощью встроенных средств удаленного интерпретатора Pycharm. Конечно не во всех ситуациях это хороший вариант, но для правки, и доработки небольших проектов очень даже подходит. А если проект с нуля, то создавая его на удаленном сервере, исчезает потребность в переносе и адаптации его под сервер(хостинг), которые неизбежно ведут к появлению множества багов и несовместимостей.

К тому же такой подход нас избавляет от таких проблем:

• на разных серверах свой Unix и свои приколы, разворачивать локально и подгонять среду под особенности того или иного сервера может занять приличное количество времени;
• разные версии python;
• И если в файле req.txt для Django не указаны все зависимости;
и т.д.

Процесс настройки удаленного интерпретатора Pycharm для Django


Идем в file-> settings-> deployment



Вводим настройки подключения сервера, у кого какое (SFTP, FTP, и т.д.). В поле «root path» – нужно указать путь к папке с проектами. Во вкладке «Mapping» в поле «Deployment path on server» необходимо указать путь от «root path» к папке с проектом.



К примеру:
«root path» = /data/python
«Deployment path on server» = /project
Под deployment есть options, в них полезно выставить выгрузку файлов на сервер по горячим клавишам, например, ctrl+s и другие настройки.

Подготовка закончена, переходим соответственно к самой настройки удаленного интерпретатора.



Настройка интерпретатора не сильно отличается от настройки deployment (кнопкой «Fill from deployment server settings» можно заполнить часть настроек). Нажимаем «Configure Interpreters», выбираем remote, или если уже какой-то был создан, то с помощью плюсика. Далее необходимо указать путь к интерпретатору python на сервере. После нажимаем «ok» и немного подождать пока Pycharm скачает (создаст) образ skeleton python в месте с приложениями которые были установлены через pip или подобное ему, что очень удобно, в последствии можно спокойно переходить к этим файлам из кода!

Следующим шагом будет настройка запуска Django сервера используя средства Pycharm для разработки.



В инструментах с права выбираем «Edit configuration»



В появившемся окне вводим «host» 0.0.0.0 для того что бы с любого ip принимал вызовы и «port» который у Вас является свободным на сервере. Выбираете удаленный интерпретатор в поле «Python interpreter», который настроили раннее. В поле «Environment variables» необходимо указать переменную «DJANGO_SETTINGS_MODULE» и ее значение, состоящее из названия главного приложения Django и файла с настройками в нем.



На этом настройка удаленного интерпретатора завершена, для его запуска можно воспользоваться кнопкой на панели инструментов с права.



После с низу появится окно логов сервера со всевозможными инструментами.



Стоит отметить что помимо удаленной отладки в Pycharm встроили очень полезные инструменты(menu-> tools): SSH-клиент, Django-console, Python-console, Debug, и прочие.

На скриншоте ниже Django console и SSH-клиент в режиме сплит.



Заключение
Способ разработки (отладки), который был представлен выше, по сути является попыткой выхода на новый уровень. Развертывание разработки на локали – это как запатентованный проверенный способ, ну а описанный выше является новым подходом, и никто не гарантирует его поддержку, хотя JetBrains стараются, но как известно первые всегда набивают шишки. Удачи.

P. S.
Так же при настройке удаленного интерпретатора можно использовать virtualenv, где при разработке или доработке проекта можно проводить абсолютно независимые тесты и не влиять на сервер, но это отдельная тема.
  • +18
  • 29.3k
  • 7
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 7

    +5
    ИМХО с этого P.S. надо было начать и написать все то же самое с учетом virtualenv
      0
      Больше хотелось показать, то что такой вариант есть. Для начинающего разработчика подойдет, virtualenv имеет свои тяготы в настройке и там много описывать надо. Ну а так Ваш комментарий весьма оправдан.
        +3
        надо сразу начинать с хорошего
          0
          Нет никакого смысла не пользоваться virtualenv
          +1
          Для более-менее сложной разработки лучше использовать vagrant, тем более что его поддержка есть в PyCharm. Если еще настроить автоматический provision — то это позволит без проблем передавать проект другому разработчику ( или хранить настройки виртуального окружения в git ).

          А virtualenv не всегда может помочь. Например — разработка и продакшен ведутся на разных платформах (Windows / Linux), или разные версии серверов БД (и подобных) которые не смогут ужиться вместе на одном хосте.
            0
            Так конечно лучше vagrant, а еще лучше docker, а еще лучше dokku, а еще лучше dokku + ansible с самого начала и проблем не знать. Мой коментарий был о том, что сегодня не использовать ни каких средств изоляции среды очень странно.
          +1
          > А если проект с нуля, то создавая его на удаленном сервере, исчезает потребность в переносе и адаптации его под сервер(хостинг), которые неизбежно ведут к появлению множества багов и несовместимостей.

          Это потрясающее объяснение для того, чтобы выстрелить себе в ногу

          Only users with full accounts can post comments. Log in, please.