cannot set remote breakpoints in visual studio 2019 IDE

When I click to set a breakpoint manually in the IDE, I get the message "Breakpoint will not currently be hit. Breakpoint in file that does not currently exist." I can, however, attach to the process, step through code, and stop at breakpoints set programmatically. From reading the docs, I believe this is supposed to “just work” in Visual Studio 2019.

PTVSD was installed with conda and the environment is active when running the source code.

$conda list ptvsd
<...>
# Name                    Version                   Build  Channel
ptvsd                     4.3.2            py27h516909a_0    conda-forge

$python --version
Python 2.7.15

The code is running on Ubuntu under the Windows Subsystem for Linux. In Visual Studio I open the folder and file, then go to Debug->Attach->tcp://localhost:5678. The Visual Studio “Current Python Environment” is set to 2.7.

I am running my python module simply with python mycode.py, and the file contains:

import ptvsd
ptvsd.enable_attach()
ptvsd.wait_for_attach()

Aside - I’m unsure whether this is related to pathmappings and if so, how does one set that for VS2019. I am not using VS Code.

[int19h]

The root cause is what Hugues explained earlier.

In ptvsd 3 - the legacy one - breakpoint matching was done on the basis of qualified module name, which it obtained by walking the filesystem on both ends and observing __init__.py. This meant that the user didn’t have to set up any explicit path mappings. But it broke as soon as Python added namespace packages (which are just regular folders).

In more recent versions, and in debugpy, we inherit pydevd behavior, which requires explicit path mappings to be specified (and thus also works with any Python version). This is done via launch configuration, so for VSCode, the users just add it to their launch.json:

https://code.visualstudio.com/docs/python/debugging#_remote-script-debugging-with-ssh

For VS, there was no such way, so it had to be wired up into project settings somehow. Or maybe expose a generic facility for the users to add raw JSON configuration directly - since this sort of thing will come up with any other feature that is controlled via configuration, it might be a good idea to have a catch-all like that, and then gradually implement UI settings for those parts of JSON that are commonly used.

[bschnurr]

@int19h any thoughts?