Cppdbg in Ubuntu 24.04 defaults Python in (nonexistent) AppImage

Bug Reports
1

(Note: It’s not clear if bug reports should be filed here or on GitHub (?)… so would be nice to have a clarification on that point!)

When configuring C++ debuggers in launch.json, I found that {“type”: “cppvsdbg”} could not work in Windows with MSVC, due to Microsoft keeping that closed-source. (It would be nice if this was explained in the error dialog, as Cursor chat did not know this was why and sent me down a rabbit hole before just Googling it.)

Rather than install MinGW, I decided to try Cursor under Linux in a virtual machine, and made my launch.json contain multiple configurations. VSCode on Windows could use the Windows configuration, and then Cursor on Linux could use the Linux configuration. (If you’re curious how to switch between them, there’s a spot in the status bar for doing so…)

I made a configuration that worked under VSCode on Linux for debugging:

{
    "name": "Linux Debug",
    "type": "cppdbg",  // not MSVC's "cppvsdbg"
    "request": "launch",
    "program": "/path/to/the/program",
    "args": [],
    "stopAtEntry": false,
    "cwd": "${workspaceFolder}/wherever/",
    "environment": []
    // v-- cppvsdbg uses "console": "newExternalWindow"
    "externalConsole": true,  
    "MIMode": "gdb"
}

But when I tried to start a debug session using Cursor, it complained because it was trying to run a Python it thought lived inside the mounted AppImage:

Python path configuration:
  PYTHONHOME = '/tmp/.mount_cursorDj7LqA/usr/'
  PYTHONPATH = '/tmp/.mount_cursorDj7LqA/usr/share/pyshared/:'
  program name = '/usr/bin/python'
  isolated = 0
  environment = 1
  user site = 1
  safe_path = 0
  import site = 1
  is in build tree = 0
  stdlib dir = '/tmp/.mount_cursorDj7LqA/usr/lib/python3.12'
  sys._base_executable = '/usr/bin/python'
  sys.base_prefix = '/tmp/.mount_cursorDj7LqA/usr/'
  sys.base_exec_prefix = '/tmp/.mount_cursorDj7LqA/usr/'
  sys.platlibdir = 'lib'
  sys.executable = '/usr/bin/python'
  sys.prefix = '/tmp/.mount_cursorDj7LqA/usr/'
  sys.exec_prefix = '/tmp/.mount_cursorDj7LqA/usr/'
  sys.path = [
    '/tmp/.mount_cursorDj7LqA/usr/share/pyshared',
    '/home/the-workspace-folder/',
    '/tmp/.mount_cursorDj7LqA/usr/lib/python312.zip',
    '/tmp/.mount_cursorDj7LqA/usr/lib/python3.12',
    '/tmp/.mount_cursorDj7LqA/usr/lib/python3.12/lib-dynload',
  ]
Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
Python not initialized

Looking inside the AppImage mount point there is no Python inside of it. This behavior was identical for either running with a configured apparmour or the --no-sandbox option (I wasn’t sure if saying ‘no sandbox’ meant something about not using a Python in the AppImage or not).

Asking ChatGPT and Claude they tried to suggest tweaking the "environment": [] in the launch.json to add PYTHONPATH and PYTHONHOME. But this had no effect. Further I realized that putting garbage for PYTHONPATH and PYTHONHOME in the environment didn’t lead to any problems in launching from plain VSCode under Linux. So it seems that it was something going wrong before the launch.json was being interpreted.

I found that setting PYTHONPATH and PYTHONHOME in my environment explicitly before launching Cursor solved the problem. On Ubuntu 24.04 I just did this in my ~/.profile file.

# Some programs like cursor default their own pythonhome and
# pythonpath if not explicitly set.
#
PYTHONHOME=/usr
PYTHONPATH=/usr/lib/python3.12

With that set and rebooting, I was able to debug successfully. So basically, it seems that the “guessing” logic for the paths wound up guessing inside the AppImage mount when that can’t be right as there’s no bundled Python.

(I report this as a bug, because setting these variables was not necessary for VSCode to work under Linux for the same debug scenario.)

1 Like
2

Jupyter Notebook is effected by this error, too. The kernel just refuses to start.

1 Like