Remote Python Debugging Ignores Path Mapping if the Remote Path is Accessible


I saw a single post about this before, but it was a long time ago and had no responses.


I'm just going to explain what I'm doing. It's not a rare circumstance considering how Python is very commonly used for plugins.

I develop an addon for Kodi. Due to the nature of Kodi's virtual python environment (python called from C++ with black magic in there somewhere), it's basically impossible to debug "locally". I set up remote debugging and it works...mostly. The issue is that it always opens %appdata%/Kodi/addons/../ instead of the that I have open in front of me. I have tried path mappings, and I don't want to mess with permissions just to make it obey a setting that should ALWAYS be obeyed if populated. It'll more than likely cause more problems than solve.

I could throw Kodi on another machine and actually remote debug, but...why? That serves no benefit.

"If I can access the files that are actually running why would I want to use the workspace ones?" is the question that I'm expecting to get. BECAUSE I'M DEBUGGING. The files are up to date. They haven't changed, but I can't hit any breakpoints that I place, because it decides that files that are not in my workspace are better.

You know what Rider does better? This. Debug a file, it says hey you have that file. If the source doesn't match, then it tells me, which can solve some problems by itself, as I'll know that the build isn't updating. The only reason it shows me the remote (decompiled) source is because I don't have a copy. This is how it should work. I already have everything open. Don't open another copy elsewhere on my computer if I am already looking at it. Use the breakpoints that I'm looking at. When I say step through, use my workspace files.

If you need a good reason as to why path mappings should ALWAYS be obeyed, then here's an example:

I have a stable, not current version of the code installed on my computer. I spin up a VM to test on, and it has an identical file structure, almost like I want the dev environment as close to production as possible. It's available, but not relevant. I remote debug, and PyCharm, in its vast intelligence, decides to ignore the mappings that I gave it and use the stable release instead. Unfortunately, that release is before a major refactor and is completely useless.

Remote debugging should still act remote even if it's not. Sorry about the rant, but I've been trying to figure this out and debug an issue for literally the past 12 hours. I could probably go use a free software like Eclipse for this, but...this feature is paid for.... I shouldn't need to rant about this.


Does anyone have a decent solution that doesn't involve waiting for an update to PyCharm?

My guess would be a way to isolate that folder from PyCharm so it won't think I have access to it without breaking Kodi, but I don't know of such a thing in Windows.

Even if it's just a sad excuse behind the stupid idea to ignore Path Mappings, I would like to hear from JetBrains on this one. It sounds like one of those things that seemed like an idea to solve network latency issues but backfired miserably.


I suppose I'll be asked what version I'm on. 2018.3.4. I guess it's latest stable atm.


Hi Thomas,

I tried setting up following the documentation and it seems to be working just fine.

Would be great if you could upload your project or its relevant part for reproducing to zipped and let me know the name of that file. Screenshots of configuration would be also helpful.


It might be somewhat difficult to reproduce unless you install Kodi and run it. is the full repository. `git clone --recursive` will give a fully functional workspace. is where it is called.


I'll keep trying to diagnose it, as well. In case you missed it, the "remote" path is not remote. It is in C:\Users\da3ds\AppData\Kodi\addons\, while the local path is in C:\Users\da3ds\Documents\GitHub\Nakamori\ It refuses to take the path mappings because it is local. I just tried it on a remote machine, and it worked that way. I would use "Attach to Process", but it's a script, and it doesn't stay open long enough to attach.


Please attach a screenshot of your Remote Debug configuration.

Also, do you have .egg file in your project and the similar lines in your file?

import sys
import pydevd

import pydevd
pydevd.settrace('', port=12345, stdoutToServer=True, stderrToServer=True, suspend=False)

This is an example from documentation so there can be a difference.


These are my settings:As shown in the picture, debugging does work, but only in files that are not in my workspace. I have them on my computer, but it should map them, anyway.


I believe you should change the mappings so that your local project directory is mapped to the remote project directory (empty in your case).

Also, is your machine accessible with localhost:5678?

Please check the documentation for details.

Is there a particular reason to use remote debug server configuration instead of debugging through remote interpreter?


localhost is accessible from localhost, yes. No offense, but it feels like you aren't actually reading the my posts. I've said it a few times in a few different ways to avoid misunderstanding. PyCharm's remote debugger is on the same machine as the running code, but the code is not run from PyCharm. The code is run from a C++ call with injected variables. It's a plugin. I can't just run it in PyCharm. If there's a better way to do this rather than Remote Debugging, then by all means, I'd appreciate the knowledge.


The path mappings also specify the base paths before the explicitly. I've tried every combination of with or without each mapping.


That ought to make it as obvious as possible as to what I am doing. The settings and all of that are posted in previous posts. Ignore the web-pdb thing. It does PyCharm debugging first, and falls back on web-pdb if a dev doesn't have a PyCharm Pro license.


Hi Thomas, thank you for the screencast, I reproduced the problem. Unfortunately, remote debug server path mappings are not respected correctly (PY-18491). In general PyCharm should figure out you have a "local" copy in the project and suggest to open it instead but it doesn't seem to work in case of the local machine as far as I can see right now, I created a ticket for the responsible developer to investigate further PY-34001. I am sorry for the inconvenience.


Thanks for the useful response. It's a bit discouraging to see that's been reported for 3 years without even a workaround, but it's better than denying that there's an issue. I'll deal with it or debug remotely (as not on the same machine) until then, I guess.


Please sign in to leave a comment.