fix(install): preserve pip entry point when re-running on symlinked install

setup_path() writes the user-facing hermes shim with `cat >`, which
follows existing symlinks. Older installs created
`$command_link_dir/hermes` as a symlink to `$HERMES_BIN`
(`venv/bin/hermes`), so re-running install.sh stomped the pip entry
point with a bash shim that exec'd itself in an infinite loop.

`rm -f` the link target before writing so the shim lands at
`$command_link_dir/hermes` and the venv entry point is left intact.

Adds a regression test that reproduces the symlink-stomp end-to-end
(creates the symlink, drives the real shim-write block from setup_path,
asserts the venv pip script body survives and the shim is now a regular
file). Both new assertions fail on origin/main and pass with the fix.

Closes #21454.
This commit is contained in:
Tranquil-Flow 2026-05-08 05:16:19 +10:00 committed by Teknium
parent ddb8d8fa84
commit c75e1a03f9
2 changed files with 127 additions and 0 deletions

View file

@ -1281,6 +1281,10 @@ setup_path() {
# We intentionally clear PYTHONPATH/PYTHONHOME here so inherited env vars
# can't make this launcher import modules from another checkout.
mkdir -p "$command_link_dir"
# Older installs created this path as a symlink to $HERMES_BIN. Without
# the rm, `cat >` follows the symlink and overwrites the venv pip entry
# point with this shim — making `exec "$HERMES_BIN"` self-recurse. (#21454)
rm -f "$command_link_dir/hermes"
cat > "$command_link_dir/hermes" <<EOF
#!/usr/bin/env bash
unset PYTHONPATH