uv_install() (host-setup/linux/install-tools.sh:515-527) always installs uv/uvx to /usr/local/bin ($BIN_DIR) via a downloaded GitHub release binary, regardless of how uv already got onto the host. But #483's own install matrix documents the officially supported Linux install as curl -LsSf https://astral.sh/uv/install.sh | sh, which installs to ~/.local/bin. On a stock Debian host, ~/.profile prepends ~/.local/bin ahead of /usr/local/bin on PATH, so a uv installed the documented way permanently shadows the one this script manages.
tool_note() (line 674, case jq | uv | git-restore-mtime) already detects this and prints a note: "$resolved is installed outside $BIN_DIR and keeps answering once the managed copy is installed" (line 682). But nothing acts on it. --install/--upgrade uv only ever touches $BIN_DIR; the shadowing copy is left in place. The result doesn't converge: every subsequent --report re-detects and re-prints the same note, uv --version on PATH keeps answering with the old version, and an operator following #483's own documented install command is guaranteed to reproduce this on the next uv reinstall/self-update.
Repro:
curl -LsSf https://astral.sh/uv/install.sh | sh # the documented method, from #483
host-setup/linux/install-tools.sh --report # notes the shadow
host-setup/linux/install-tools.sh --upgrade uv
host-setup/linux/install-tools.sh --report # same note, unchanged
uv --version # still the old, ~/.local/bin copy
Same code path (line 674) also covers jq and git-restore-mtime, so the same class of defect applies to either of them if installed by some other officially-documented method into a directory ahead of /usr/local/bin on PATH -- not verified for those two, only for uv.
Ask: pick one side, so the report converges instead of re-flagging forever.
Either way, the report should stop being able to say the same thing on every run without anything having changed.
uv_install()(host-setup/linux/install-tools.sh:515-527) always installsuv/uvxto/usr/local/bin($BIN_DIR) via a downloaded GitHub release binary, regardless of howuvalready got onto the host. But #483's own install matrix documents the officially supported Linux install ascurl -LsSf https://astral.sh/uv/install.sh | sh, which installs to~/.local/bin. On a stock Debian host,~/.profileprepends~/.local/binahead of/usr/local/binonPATH, so auvinstalled the documented way permanently shadows the one this script manages.tool_note()(line 674, casejq | uv | git-restore-mtime) already detects this and prints a note: "$resolvedis installed outside$BIN_DIRand keeps answering once the managed copy is installed" (line 682). But nothing acts on it.--install/--upgrade uvonly ever touches$BIN_DIR; the shadowing copy is left in place. The result doesn't converge: every subsequent--reportre-detects and re-prints the same note,uv --versiononPATHkeeps answering with the old version, and an operator following #483's own documented install command is guaranteed to reproduce this on the nextuvreinstall/self-update.Repro:
Same code path (line 674) also covers
jqandgit-restore-mtime, so the same class of defect applies to either of them if installed by some other officially-documented method into a directory ahead of/usr/local/binonPATH-- not verified for those two, only foruv.Ask: pick one side, so the report converges instead of re-flagging forever.
$BIN_DIR-- the same pattern this script already uses forgh/node, which ride the vendor's own apt repository rather than a parallel binary. Would also resolve the Per-host-type tooling install matrix (implements the host-setup contract) #483 doc/script disagreement by making the script the thing Per-host-type tooling install matrix (implements the host-setup contract) #483's matrix should point to.tool_notefinds a shadowing copy,--install/--upgraderemoves it (or offers to, with--yescovering unattended), so$BIN_DIRis what's actually onPATHafterward.Either way, the report should stop being able to say the same thing on every run without anything having changed.