Unable to debug pythonw apps on macOS

[jrockwar]

After updating the extension, the debugger doesn't allow debugging pythonw apps anymore. Instead, it tries to launch python, which makes it unusable for wxpython development on MacOS.

Reverting to v2020.3.71659 solves the issue.

Environment data

• VS Code version: 1.46.1 (cd9ea64)
• Extension version (available under the Extensions sidebar): XXX
• OS and version: MacOS Catalina 10.15.5
• Python version (& distribution if applicable, e.g. Anaconda): Miniconda 4.8.3 + Python 3.7.0
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda
• Relevant/affected Python packages and their versions: wxPython v4+ (at least, older versions are possibly affected as well)
• Relevant/affected Python-related VS Code extensions and their versions: XXX
• Value of the python.languageServer setting: XXX

Expected behaviour

When debugging a python app with pythonw in the launch.json settings, the debugger should load the file using pythonw.

Actual behaviour

The following error occurs:

Exception has occurred: SystemExit
This program needs access to the screen. Please run with a
Framework build of python, and only when you are logged in
on the main display of your Mac.

Which is simply caused by MacOS not granting access to the screen to python. Normally, this is solved by running apps using pythonw, but the latest versions of the python extension ignore the setting in launch.json.

Steps to reproduce:

Create any wxPython app and try to debug it on a Mac. Example:

import wx
import sys

class WxApplication(wx.App):
    def __init__(self):
        wx.App.__init__(self)

def main():
    WxApplication()

if __name__ == "__main__":
    sys.exit(main())

This will happen regardless of the "pythonPath" setting in launch.json.

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

[int19h]

Can you share your launch.json config?

[jrockwar]

Yes, here it is:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "pythonPath": "/Users/jrockwar/opt/miniconda3/envs/wx/bin/pythonw",
            "args": ["--host_ip", "127.0.0.1"]
        }
    ]
}

I have been digging into the history of releases and this issue started happening matching the change from python.pythonPath to python.interpreterPath (in the may release). However, if I'm not mistaken, the correct setting in the json file would still be pythonpath, so in case I wanted to match my interpreter it would be: "pythonPath": "${config:python.interpreterPath}". (Which still not addresses the fact that I want it to use pythonw, since it will use python even if my interpreter is set to pythonw).

[int19h]

The canonical name for the setting from debugpy perspective is now just "python" (to avoid confusion with PYTHONPATH), but we haven't updated the extension side yet - so "pythonPath" is still fully supported by debugpy, and it's what you'll see in completions for launch.json in VSCode. But yes, it's quite likely that the regression here has something to do with that change.

The deprecation of "python.pythonPath" is more complicated than just replacing it with "python.interpreterPath" - see microsoft/vscode-python#11789 on how to handle this correctly.

[int19h]

The root cause here is very similar to #262. The debug adapter correctly applies "pythonPath" when spawning the launcher; the launcher then uses sys.executable to spawn the debuggee, on the assumption that it's the same thing.

Problem is, on macOS, pythonw is not actually a separate Python interpreter (like it is on Win32), but rather a wrapper app bundle that spawns python as a child process. So if you look at sys.executable from the launcher, you see python - and that's what's used to spawn the debuggee.

The fix will be for the launcher to instead parse "pythonPath" itself, duplicating that logic from the adapter.

[stephan-jacobs]

For what it's worth, I have this exact same issue. I also use wxPython and I would love to be able to debug from vs code. My setup is not different enough from OP to really warrant posting a bunch of information but I can provide some if you need anything. Mainly wanted to add a vote asking for this to be fixed :)