Remote debugging opens up in remote sources folder
I just updated from PyCharm Professional 2020.1 directly to PyCharm Professional 2022.3.1 and the remote debugging ended up working correctly in my projects.
When I now try to begin a remote debugging of any python file by adding a breakpoint, the debugger stops at that line but it opens a new tab pointing to a copy of the file under the "remote_sources" folder. Normally, when I was debugging, this would only happen to me with source files that are external to my project. What could be the problem?
An example of how stops in the correct line but opens the copy from the remote sources.
The settings were automatically imported from the old version into the new version and the old version still works properly (luckily I still have the old version installed).
Some more info:
- I have the deployment settings set up correctly and in "Automatic upload". Files are synced.
- The deployment settings are used for the Remote Python Interpreter in that exact same machine.
- The mapping between the local and remote folder paths is correct on the Python Interpreter settings page.
- The project I'm working on is installed using pip install -e . in the remote Python.
- My PYTHONPATH in the remote machine is empty
- No directory is marked as Sources Root in my project.
Thank you so much for the help!
Please sign in to leave a comment.
+ info: If I uninstall my package in the remote Python in order to undo the pip install -e, then it works properly (it doesn't open up the copy in the remote sources when debugging). So the problem should be related to that... But I can't take that as a fix as I need it installed on my remote machine in order to run other projects.
This problem seems to be related to this issue (https://youtrack.jetbrains.com/issue/PY-42084/python-debugger-with-linux-soft-links-symlinks) although I don't have any symlink set up in my project. The issue seems to be directly related to the installation of the project in editable mode directly in the remote python interpreter with pip install -e.
Manual solution that I found reading the above issue:
Hello,
This sounds like a known issue https://youtrack.jetbrains.com/issue/PY-25868/Cant-go-to-declaration-when-using-remote-interpreter-source-and-e-flag , the description of the problem is https://youtrack.jetbrains.com/issue/PY-25868/Cant-go-to-declaration-when-using-remote-interpreter-source-and-e-flag#focus=Comments-27-2705913.0-0
You may try marking the folder as a source root, unfortunately there is no workaround for this behaviour at the moment.
Hi, I have just tried and I don't have any issues with "Go to Declaration" even if I don't have the project folders marked as source root (it takes me to my local file correctly).
Also, marking the project folders as source root does not fix the issue. Only the manual solution that I mentioned in my previous comment seems to work.
I fix it by doing the following:
1 - Uninstalling my package from the remote environment (pip uninstall mypackage)
2 - Invalidating caches (clear file system, clear VCS,...)
3 - Restarting Pycharm
Hi Antonina Belianskaya,
I'm facing the same issue. In addition, when debugging the new file opened is not updated with my local version (although it stops in the same line I put the breakpoint). But when I manually entered the server and viewed the debugged file it corresponds to my local version.
How can that be fixed? This is really annoying issue.
Mista2311Do you have path mappings configured in your run/debug configuration, and is the issue reproduced if you do?
I have the exact same problem. Manually adding the path mapping again in the "Run -> Edit configurations..." menu is really not a convenient option... Also, i don't get why this is necessary. In the deployment settings the mapping is already properly defined. Also, in earlier PyCharm versions I could add path mappings directly in the interpreter settings. This is no longer possible apparently... Equally it's not possible anymore to change the ssh connection of an existing interpreter which is quite bad as well.
In earlier PyCharm versions both never was a problem.
I am using version PyCharm 2023.1.1 (Professional Edition) on Mac OS Ventura.
I really hope these issues are getting fixed, since currently the newest version seems like a proper downgrade instead of an upgrade...
I have the same problem too, and I make sure this problem exist for a long time.
when debug on remote python interpreter, open the code file is not the project file, but a different file in cache system.
Daniil Bogdanov I don't think this is a new feature of the latest PyCharm version. In earlier versions one could always set path mappings for a remote project under "Preferences | Build, Execution, Deployment | Deployment, Mappings". As previously described, in earlier versions that was enough to properly work on a remote server and debug project files. However, in 2023.1.1 on Mac OS Ventura one has to manually set the path mappings for every single Project file one wants do debug in "Run | Edit configurations... | <file> | Path mappings". Then debugging works as expected.
However, setting over and over again the same mappings for all files in a project cannot be intended behaviour and is seriously annoying...
Here (https://www.jetbrains.com/help/pycharm/edit-project-path-mappings-dialog.html) it even says:
"If in the current run/debug configuration you use an interpreter accessible through SFTP connection or located on a Vagrant instance or in a Docker container, the mappings are automatically retrieved from the corresponding SFTP deployment configuration, Vagrantfile, or Dockerfile, and listed in the dialog. These mappings are read-only."
However, that does not seem to work... Although the mappings are properly set in the deployment configuration, they are not automatically retrieved for each run/debug configuration file.
By the way, what might be related to the issue is that PyCharm creates a new deployment configuration for every project on the same remote server (see screenshot). In earlier versions that did not happen either... However, the sftp/ssh deployment configuration should exists once for the server and multiple projects share the same connection...