You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@magpie.apache.org by "potiuk (via GitHub)" <gi...@apache.org> on 2026/09/18 16:54:31 UTC

[PR] fix(agent-isolation): pick a python that can import gi for the touch overlay [magpie]

potiuk opened a new pull request, #1279:
URL: https://github.com/apache/magpie/pull/1279

   ## Summary
   
   - `gpg-touch-overlay.sh` probed `python3 -c 'import gi'` to decide whether it could draw the full-screen GTK overlay. That assumes the PATH `python3` is the one carrying PyGObject.
   - On a host where Homebrew / pyenv / asdf puts its own `python3` first, the probe fails even though the distro's `python3-gi` is present and working under `/usr/bin/python3` — so the overlay silently falls back to the small zenity dialog.
   - Replaces the assumption with a resolver (`_gi_python`) that returns the first interpreter which actually imports `gi`, used by both `_overlay()` and `arm()`'s availability guard.
   
   ## Motivation
   
   Found on a Linux host with Homebrew's `python@3.14` ahead of the system `python3` on PATH:
   
   | Interpreter | `import gi` |
   |---|---|
   | `python3` → `/home/linuxbrew/.linuxbrew/bin/python3` (3.14.7) | `ModuleNotFoundError` |
   | `/usr/bin/python3` (3.12.3) | OK |
   
   The failure mode is quiet. The overlay still appears, just as a plain 560px zenity box, so it reads as "the window got worse" rather than "a dependency probe is looking in the wrong place". The whole point of this hook is to make an invisible block visible; degrading to the fallback when the good path is available undercuts that.
   
   `arm()` carried the same assumption in the `gi` half of its `zenity || gi` guard. It happens to be masked whenever zenity is installed, but on a host with gi and no zenity it would bail and show nothing at all.
   
   ## Migration path for existing adopters
   
   None required. No config, no new dependency, no behaviour change on a host where `python3` already imports `gi` — that interpreter is still tried first. Hosts with neither gi nor zenity keep the existing silent no-op.
   
   ## Test plan
   
   - `prek run --all-files` — all hooks pass. (Note `skill-token-count` needs its tokenizer cache under `~/.cache`, so it must run outside the isolated sandbox; verified there.)
   - `tools/agent-isolation/tests/test_gpg_touch_overlay.py` — 18 passed, including the new `test_gi_python_only_reports_an_interpreter_that_can_import_gi`, which asserts the selected interpreter can genuinely import `gi` and skips where no interpreter can.
   - Manual on the affected host: `_gi_python` returns `/usr/bin/python3` (exit 0) where the old bare probe failed; `gi`/`Gtk`/`Gdk`/`GLib` all import under it and `gpg-touch-overlay-window.py` parses clean.
   - The equivalent fix is already running in my own config, where it restored the full-screen overlay.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] fix(agent-isolation): pick a python that can import gi for the touch overlay [magpie]

Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk merged PR #1279:
URL: https://github.com/apache/magpie/pull/1279


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org