Pycharm uploading files to wrong server after updating run config
Hi,
I have two remote machines and I switch the machines to run my code on from time to time. When I want to run it on the other machine, I edit my run configuration to use the other remote interpreter. Then I change stuff and click run. However, Pycharm is still uploading the file to the machine with the previously configured python remote interpreter. Pycharm does run the code on the new machine, but doesnt update the files.It runs an old version of the code that is still on that machine from previous run, so apparently it used to work.
I changed the default project environment, but Pycharm is still uploading the files to the wrong server. I also tried making a new configuration with the new machine, still files are not updated correctly. I am using 2018.3 version.
I assume this is a bug? Can I do anything about this except manually doing the file uploads?
Greetings
请先登录再写评论。
Hi Adrian,
If problem is only with files not being uploaded from one machine to another (newer version of the files), then probably you should check Deployment configuration.
The very idea around which IDE works with remote and local files is that local files go first and remote files go second. It means that you make changes on local machine and then upload them to remote host. Do you have automatic upload enabled? (Settings/Preferences | Build, Execution, Deployment | Deployment | Options).
Yes it is enabled. Pycharm does make the automatic upload, but it does it to the wrong server!
So first I have this: Run configuration uses remote interpreter_1. I make a local change on my working machine, run the configuration. Pycharm automatically uploads the changes to server_1, and runs it. Everythings fine as expected.
Now I make another change, but now I want my code to run on server_2. So I edit my run configuration, and change the python interpreter to interpreter_2 (which is located on server_2). I click run, and Pycharm automatically uploads my local change to server_1. It then tries to run the code using interpreter_2 on server_2, and fails because the files are not there - as they were wrongly uploaded to server_1. Its like the file upload doesn't realize that I changed the python interpreter, and therefore still uploads it to the server that was previously configured.
Weird thing is that I am pretty sure it used to work, I have several run configurations using different remote interpreters and never had to manually upload any files. But now, no matter which interpreter is configured, all files are always uploaded to one specific server.
Seems like a bug with PyCharm not switching deployment configuration indeed. Here is a corresponding issue https://youtrack.jetbrains.com/issue/PY-33981, please vote for it and follow for updates.
Same issue here with Pycharm Pro, very frustrating. I've changed the remote interpreter to the 2nd server, changed the remote browser too, ssh session in terminal is running with the new server too. I've even checked and there is no default upload server set. Still my files are being auto-updated to the old server, the wrong one. Restarting doesn't help, uploading manually to the new server doesn't fix autoupload destination either. Can't even use auto-upload anymore on my new server.
Thanks Jiri, good eyes! There is no noticeable label in the server list showing that the default server can be set here. If you didn't point it out I would never have noticed that the little checkmark next to the plus and minus signs serves the purpose of selecting default server (which then also gets a slightly different color (blue background). There is a pop-up message once you hover over the check mark and leave the cursor there for a few seconds but I think it would be awesome if someone at IntelliJ added here some more noticeable label.
Anyways, this works now thanks!
Of course like others mentioned above, if the default upload server was somehow automatically detected and matched the selected remote interpreter (or probably better yet, the server whose files are being browsed in the remote browser), that would make it one step easier for us.