Lorsque je lance PyCharm pour l’interpréteur python distant, il effectue toujours un "téléchargement d’aides PyCharm", même lorsque l’IP de la machine distante est identique et contient déjà des aides précédemment téléchargées. Le comportement est-il correct?
Il s’agit d’un problème bien connu qui peut constituer un obstacle majeur à la productivité, en particulier si vous utilisez des instances jetables dans votre flux de travail. Il en résulte une pause café forcée de 20 minutes à chaque fois que vous souhaitez vous connecter à un système distant. Inacceptable.
On dirait que PyCharm crée un fichier build.txt dans le dossier d'assistance distant qui ne contient que le numéro de build PyCharm actuel, par exemple:
PY-171.4694.38
Il est donc possible de télécharger les aides manuellement en utilisant rsync
sur /Applications/PyCharm.app/Contents/helpers/
et enfin de créer manuellement un fichier build.txt avec votre numéro de version actuel. Après cela, PyCharm ne devrait plus tenter de les télécharger à nouveau.
Exemple:
$ 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
Notez que - du moins aussi tard que la version 2018.3.x - PyCharm semble également nécessiter le ré-téléchargement des aides lorsque la connexion réseau local est également modifiée, pour une raison quelconque.
Ce que j’ai observé dans mon cas, c’est que si, tant que PyCharm est en cours d’exécution, je déplace mon ordinateur portable et que je me connecte à un autre réseau local, la prochaine session de débogage à distance que j’initierai déclenchera le téléchargement de longue durée. Il s'avère que le contenu du répertoire helpers réellement chargé dans ce cas est exactement identique au contenu déjà présent dans ce répertoire sur le système distant (je les ai comparés), ce téléchargement est donc totalement superflu, mais PyCharm n'est pas en mesure de le faire. détectez ceci.
Comme il n’ya aucun moyen, à ma connaissance, dans PyCharm d’ignorer ou d’annuler le téléchargement automatique des assistants, le seul recours est de quitter complètement PyCharm (fermez toutes les fenêtres de projet ouvertes) après chaque changement de connexion réseau et de redémarrer l’EDI. D'après mon expérience, le téléchargement de l'assistant réussira dans la phase de "vérification des assistants distants", avant de télécharger à nouveau tous les assistants. Bien sûr, il s’agit d’un désagrément majeur si vous avez plusieurs projets ouverts, mais c’est plus rapide que d’attendre les (dizaines de) minutes qui suivent la fin du téléchargement angoissant des helpers.
Tout ce que les autres répondants décrivent sur la marche à suivre lors du changement de version de PyCharm est vrai. Il suffit d’utiliser rsync, ftp, scp ou autre pour transférer le contenu du nouveau répertoire local helpers
(sous Linux, un sous-répertoire où l’application est installée) vers le système distant (sous Linux, ~/.pycharm_helpers, où ~ est le répertoire de base du nom d'utilisateur utilisé pour la session de débogage distant) et met à jour le build.txt
distant dans le répertoire helpers avec la nouvelle version de PyCharm.
solution rapide (moins de 3 secondes entre moi et digitalocean) inspirée par excellente réponse de xApple
sur un serveur distant:
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
sur votre poste de travail:
export TARGET=<remote server ip>
export PORT=9000
export HELPERS=<path to helpers> # for me it's $HOME/opt/pycharm-2016.3/helpers
cd $HELPERS
tar cfz - . | netcat -v $TARGET $PORT
Selon les docs ,
PyCharm vérifie la version des assistants distants à chaque exécution à distance. Ainsi, si vous mettez à jour votre version de PyCharm, les nouveaux assistants seront automatiquement téléchargés et vous n'avez pas besoin de recréer un interprète distant.
La désactivation du pare-feu a résolu le problème dans mon cas (macOS - Mojave). Notez qu'il ne s'agit pas d'une solution générale, car elle n'a été testée dans aucun autre environnement/système d'exploitation.