Pycharm всегда "загружает помощников pycharm" к тому же удаленному интерпретатору python при запуске

Ответ 1

Это хорошо известная проблема, которая может стать серьезным препятствием для производительности, особенно если вы используете одноразовые экземпляры в своем рабочем процессе. Это приводит к принудительному перерыву на кофе по 20 минут каждый раз, когда вы хотите подключиться к удаленной системе. Неприемлемо.

Кажется, что PyCharm создает файл build.txt в удаленной вспомогательной папке, в которой только текущий номер сборки PyCharm является его содержимым, например:

PY-171.4694.38

Таким образом, можно вручную загрузить помощников, используя rsync on /Applications/PyCharm.app/Contents/helpers/ и, наконец, вручную создав файл build.txt с вашим текущим номером сборки. После этого PyCharm не должен пытаться повторно загрузить их.

Пример:

 $ rsync -avz /Applications/PyCharm.app/Contents/helpers/ cluster:/home/xapple/.pycharm_helpers/
 $ echo "PY-171.4694.38" > /home/xapple/.pycharm_helpers/build.txt
 $ python /home/xapple/.pycharm_helpers/pydev/setup_cython.py build_ext --inplace

Ответ 2

Согласно документы,

PyCharm проверяет версию удаленных помощников на каждом удаленном запуске, поэтому, если вы обновите версию PyCharm, новые помощники будут загружены автоматически, и вам не нужно будет воссоздавать удаленный интерпретатор.

Ответ 3

быстрое (менее 3 секунд между мной цифровое) решение, вдохновленное отличным ответом xApple
на удаленном сервере:

export SOURCE=<your ip>
export PORT=9000
export HELPERS=$HOME/.pycharm_helpers
# PyCharm Help -> About
export BUILD=PY-172.4343.24  # 2017/10/11
cd  $HELPERS
rm -fr *
# my OS - ubuntu, change firewall rules to yours if you're not so lucky
sudo ufw allow from $SOURCE proto tcp to any port $PORT
netcat -l -v -p $PORT | tar xz # here you waiting for connection
# after finish
sudo ufw delete allow from $SOURCE proto tcp to any port $PORT
echo -n $BUILD > build.txt
python $HELPERS/pydev/setup_cython.py build_ext --inplace

на рабочей станции:

export TARGET=<remote server ip>
export PORT=9000
export HELPERS=<path to helpers> # for me it $HOME/opt/pycharm-2016.3/helpers
cd $HELPERS
tar cfz - . | netcat -v $TARGET $PORT

Ответ 4

Отключение брандмауэра решило проблему в моем случае (macOS - Mojave). Обратите внимание, что это не общее решение, поскольку оно не тестировалось ни в каких других средах/ОС.

Ответ 5

Обратите внимание, что - по крайней мере, до версии 2018.3.x - PyCharm также требует повторной загрузки помощников, когда по какой-то причине также изменяется подключение к локальной сети.

В моем случае я заметил, что если PyCharm продолжает работать, я перемещаю свой ноутбук и подключаюсь к другой локальной сети, то следующий сеанс удаленной отладки, который я инициирую, вызовет длительную загрузку помощника. Оказывается, что содержимое каталога помощников, фактически загруженного в этом случае, в точности совпадает с содержимым, уже присутствующим в этом каталоге на удаленной системе (я сравнил их), поэтому такая загрузка совершенно излишня, но PyCharm не может обнаружить это.

Поскольку в PyCharm я не знаю способа обойти или отменить автоматическую загрузку помощников, единственный выход - полностью выйти из PyCharm (закрыть все открытые окна проекта) после каждого изменения сетевого подключения и перезапустить IDE. По моему опыту, это приведет к успешной загрузке помощника в фазе "проверки удаленных помощников", прежде чем фактически снова загрузить всех помощников. Конечно, это очень неприятно, если у вас открыто несколько проектов, но это быстрее, чем ждать (десятки) минут мучительно медленной загрузки помощников для завершения.

Все, что другие респонденты описывают, как действовать при изменении версий PyCharm, верно. Для передачи содержимого нового локального каталога helpers (в Linux, подкаталога, в котором установлено приложение) в удаленную систему (в Linux, ~/.pycharm_helpers), где достаточно использовать rsync, ftp, scp и т.д. ~ является домашним каталогом имени пользователя, используемого для сеанса удаленной отладки), и обновите удаленный build.txt в каталоге build.txt новой версией PyCharm.