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!

4
24 comments

+ 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.

0

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: 

Setting up the "Path mappings" manually in the debug configuration seems to do the job. Just set up the mapping between both local and remote root folders of the project and it seems to work fine again.

1

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.

0

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.

0

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

1

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.

1

Mista2311Do you have path mappings configured in your run/debug configuration, and is the issue reproduced if you do?

0

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...

2

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.

0
In the latest PyCharm, you can set path mappings in the corresponding Deployment configurations for your remote interpreter. You can access them in Preferences | Build, Execution, Deployment | Deployment, Mappings tab.
0

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...



1

Any update on this?  I'm having this issue and it's very difficult to deal with when debugging.  I'd be happy for any workaround, but the ones offered in this thread don't seem to be applicable anymore with the latest versions of pycharm.

0

Bump. Same problem here all of a sudden.

0

Hmmm. If I unmark as sources root, then mark as sources root again it works again.

0

@geometrikal thanks for the suggestion, though that fix didn't work for me.

0

Any updates?  This is causing me lots of issues.

0

This is still causing several members on our team grief.  Is there an update or workaround on this?

0

I'm also having this problem using PyCharm 2023.2.5

I'm using Windows with my interpreter in WSL. When I hold CTRL and click on classes that are imported from my venv packages it brings me to a remote sources folder, not the file in my venv.

It shows me AppData\Local\JetBrains\PyCharm2023.2\remote_sources\…

I want it to show me <Project>\venv\lib\python3.10\site-packages\…

1

I having the same problem here.  Debugging a remote ssh project became a nightmare.

0

Any update?  This issue is now a year old.

0
Hello, 
Please create an issue in the PyCharm branch of YouTrack (https://youtrack.jetbrains.com/issues/PY) so we can investigate this properly. 
To help us investigate this problem, take screenshots of the issues, collect PyCharm logs with Help | Collect Logs and Diagnostic Data, and attach the archive to the thread.
0

Same case on my side. This prevents me from using the newer version of PyCharm. I am still using PyCharm 2022.1.4 to make it work properly. Please fix this bug as soon as possible!!! Thank you soooo much!

0

newest version is a piece of S1t with stuck closing project,high resource consume s1t named newUI and this horrible remote debug bug. I roll back to 2020.1 and feeling back home now

2

Please sign in to leave a comment.