Review feedback on the conflict guidance, both valid.
The pipx hint keyed off `.local/bin` appearing in the path, which is
where a uv-managed or hand-placed strix lands too. Telling that user to
`pipx uninstall strix-agent` either does nothing or removes a different
package, and leaves the real PATH conflict in place. Ask pipx instead:
compare the executable's directory against `PIPX_BIN_DIR` and confirm
`strix-agent` is in `pipx list`.
The `rm` suggestion printed the path bare, so copying it would split on
spaces or expand a glob. Print it through `printf '%q'`.
The decoy tests asserted that pipx was never invoked at all, which the
ownership check now legitimately does. They assert no `uninstall`
instead, which is the contract that matters. `describe_removal` only
runs when another executable wins PATH resolution, which a successful
install prevents, so the advice itself is now tested by lifting the
functions out of the script and calling them directly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`check_existing_installation` walked `which -a strix` and deleted every
match outside `$INSTALL_DIR`, and `verify_installation` deleted whatever
executable won PATH resolution. Path discovery shows that another `strix`
exists; it does not show that the installer owns it. A pipx install or a
development checkout on `PATH` was removed without being asked about,
including a `pipx uninstall strix-agent` triggered purely by the path
containing `.local/bin`.
The installer now touches only `$INSTALL_DIR`. Other executables are
reported, and when one wins PATH resolution the user is told how to
reorder `PATH` or remove it themselves.
Fixes#1262
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
