Dependency Review

Scanned Files

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the user experience for synthorg CLI installations by addressing immediate usability issues across both PowerShell and Bash environments. It ensures that the synthorg command is instantly accessible after installation, eliminating the need for manual terminal restarts or troubleshooting PATH configurations.

Highlights

• PowerShell PATH Update: The install.ps1 script was updated to immediately add the installation directory to the current PowerShell session's $env:PATH, ensuring synthorg is usable without requiring a terminal restart.
• Bash PATH Warning: The install.sh script now includes a check to warn users if a custom INSTALL_DIR is not in their PATH and provides the exact export command needed to add it.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Greptile Summary

This PR fixes two usability issues in the CLI install scripts: the PowerShell script now updates the current session's $env:PATH immediately (so synthorg is usable without restarting the terminal), and the Bash script now warns — to stderr — when a custom INSTALL_DIR is not present in PATH, including a ready-to-paste export command and guidance on multiple shell profile files.

Key changes:

• install.ps1: Replaces the fragile substring match (-notlike "*$InstallDir*") with an exact, split-and-normalise entry check (-notcontains $NormalizedInstallDir), properly handles an initially-empty user PATH, and unconditionally updates the process-level $env:PATH so the binary is callable immediately.
• install.sh: Adds a case-based PATH check after installation that prints a warning (with four >&2-redirected echo lines) and lists common shell profile files — including login-shell files (~/.bash_profile, ~/.profile) — where the export should be persisted.
• Minor edge case: The Bash PATH check normalises INSTALL_DIR's trailing slash via ${INSTALL_DIR%/} but does not normalise PATH entries themselves, so a PATH entry with a trailing slash for the same directory can produce a spurious warning (see inline comments).

Confidence Score: 4/5

• Safe to merge; changes are targeted and correct, with only minor edge-case style issues in the PATH normalisation logic.
• Both fixes correctly address the stated problems. The PowerShell changes are robust (exact match, empty-PATH guard, session update). The Bash warning is properly directed to stderr and covers login shells. The only issues found are a potential false-positive warning when PATH entries carry a trailing slash, and an inherent limitation of testing PATH inside a piped subprocess — neither blocks shipping.
• No files require special attention; both scripts are low-risk, single-purpose changes.

Important Files Changed

This is a comment left during a code review.
Path: cli/scripts/install.sh
Line: 117-118

Comment:
**PATH check only normalises INSTALL_DIR's trailing slash, not PATH entries**

`${INSTALL_DIR%/}` strips a trailing slash from `INSTALL_DIR` before building the pattern, but individual entries in `$PATH` are not normalised. If the user's `PATH` contains the same directory _with_ a trailing slash (e.g. `/usr/local/bin/`), the pattern `*":/usr/local/bin:"*` won't match `:/usr/local/bin/:`, and a spurious warning will be printed even though the binary is perfectly reachable.

A simple guard that covers this common case:
```suggestion
case ":${PATH}:" in
    *":${INSTALL_DIR%/}:"* | *":${INSTALL_DIR%/}/:"*) ;;
```
This matches both the normalised form and the same path with one trailing slash present in `$PATH`.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: cli/scripts/install.sh
Line: 116-128

Comment:
**PATH check reflects the installer subprocess's PATH, not the user's interactive shell**

When the script is run via `curl … | bash`, the spawned bash process inherits `PATH` from whatever invoked `curl` (e.g. a cron job, a CI runner, a minimal Docker container), not necessarily from the user's interactive login shell. This means:

- A false positive is possible: the warning fires even though the directory _is_ in the user's interactive `~/.profile`-sourced `PATH`.
- A false negative is possible: no warning fires because the parent process happened to have that directory in its `PATH`, even though the user's interactive shell does not.

This is an inherent limitation of piped installers and is hard to work around completely, but it may be worth adding a brief caveat to the warning message such as `"(checked against the current process PATH)"` so users aren't confused when `which synthorg` works in a new terminal despite the warning having fired.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: eaf1d74}