diff options
| author | blasty <blasty@local> | 2026-07-24 01:47:05 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-24 01:47:05 +0200 |
| commit | 2392521a1cd59420a1d75d741948dd0f03b080d3 (patch) | |
| tree | 56e668396b54e959d452991510fc29a89f68d7b6 /server/patch_server.py | |
| parent | worker: surface the real startup failure (not just "code 1") (diff) | |
| download | ida-tui-2392521a1cd59420a1d75d741948dd0f03b080d3.tar.gz ida-tui-2392521a1cd59420a1d75d741948dd0f03b080d3.tar.xz ida-tui-2392521a1cd59420a1d75d741948dd0f03b080d3.zip | |
worker: spawn under the IDA python (has ida_pro_mcp), not the TUI's
Root cause of "ModuleNotFoundError: No module named 'ida_pro_mcp'": the worker was
spawned with sys.executable — the TUI's python (~/ida-venv) which has idalib +
textual but NOT ida_pro_mcp. The package split on this box:
/usr/bin/python : idapro + ida_pro_mcp (the "IDA python")
~/ida-venv/python : idapro + textual (the "TUI python", runs the app)
Fix: WorkerClient now auto-detects a python that can import ida_pro_mcp
(IDATUI_WORKER_PYTHON override, else /usr/bin/python[3], else sys.executable) and
runs worker.py as a SCRIPT rather than `-m idatui.worker`, so it doesn't import
the textual-dependent idatui package __init__ under a python that has no textual.
worker.py itself is pure stdlib at load; idapro/ida_pro_mcp are imported at
runtime (both present in the IDA python).
Verified: detection returns /usr/bin/python; worker.py loads clean there.
Diffstat (limited to 'server/patch_server.py')
0 files changed, 0 insertions, 0 deletions
