fix(setup): resolve pip and python from PATH before installing

[ffantl-ld]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

REL-15432 — found in the ldcli setup bug bash. Targets setup-ld (#776), where internal/setup/installer.go lives.

Describe the solution you've provided

• Use whichever of pip3 and pip is on PATH instead of hardcoding pip. Recent macOS and Homebrew installs ship pip3 with no bare pip, so the install failed outright on a common developer box. pip3 is preferred so a stale Python 2 pip is never selected.
• Check every package-manager executable exists before shelling out, so a missing tool warns with what to install rather than surfacing exec: "pip": executable file not found in $PATH.
• Setup never installs tooling. It will not fall back to python3 -m pip, and will not bootstrap pip with ensurepip. Only a pip that is already present is used; when none is found, setup warns and runs nothing.
• Install into the project's virtualenv when there is one — VIRTUAL_ENV, else .venv/bin/pip, else venv/bin/pip — in preference to any pip on PATH. Dependencies belong there, and on a PEP 668 interpreter it is the only place pip can write at all.
• Recognise pip's externally-managed-environment refusal and explain it: name the project, give the two commands that create and activate a venv, and note that setup will use .venv automatically once it exists. Previously this surfaced as pip's raw error with no next step.
• InstallArgs takes the project directory, so the command previewed on the plan screen is the one that actually runs, virtualenv pip included.

Describe alternatives you've considered

• Falling back to python3 -m pip when no pip shim exists. Rejected: on Debian and Ubuntu the pip module is packaged separately, so this either fails anyway or amounts to installing tooling on the user's machine.
• Bootstrapping with python3 -m ensurepip --upgrade. Rejected for the same reason — modifying the user's Python installation is out of scope for a flag-setup wizard.
• Leaving the failure to the exec error and improving only the error screen (REL-15433). That fixes the message but still runs a command known to be absent.
• Passing --break-system-packages to force the install through. Rejected outright: that is pip's own escape hatch for overwriting an OS-managed Python, and it can break tools the system shipped with.
• Creating .venv on the user's behalf when none exists. Rejected: the wizard would be inventing project structure. It uses a venv that exists and otherwise explains how to make one.

Additional context

A project with no virtualenv at all on a PEP 668 interpreter still cannot install — that is the point of PEP 668, and forcing past it is not something setup should do. It now fails with instructions instead of pip's raw refusal. Poetry, uv, and pipenv projects were never affected, since those tools manage their own environment.

Also out of scope: known issue #3 from the bug bash — pip install does not record the SDK in requirements.txt, unlike poetry/uv/pipenv/bundler.

Testing approaches

• go test ./... passes.
• Table coverage for tool resolution: only pip3, only pip, both (pip3 wins), interpreters present but no pip (bare form kept, nothing run), nothing available.
• Install coverage: a missing tool returns Failed with guidance and never calls the runner; a present tool runs the expected argv.
• Stubbed PATH in the two pre-existing install tests that reached for a real npm, which the new pre-flight check made environment-dependent.
• Virtualenv coverage: a project .venv beats a system pip3; a venv directory works too; an active VIRTUAL_ENV beats a project one; an empty directory argument does not search relatively.
• PEP 668 coverage: the refusal returns a Failed result rather than an error, names the project directory and the venv commands, and never mentions --break-system-packages. Unrelated install failures keep their existing error path.
• Verified with a built binary on a Homebrew Mac, which carries a real EXTERNALLY-MANAGED marker: in a project with .venv, install resolves .venv/bin/pip and reports "success": true. In a requirements.txt project with no venv, it reports the refusal with the venv instructions. With PATH reduced to python3 only, it warns that pip is missing and runs nothing.

---

Note

Overview
Makes ldcli setup install Python SDKs into a real environment instead of hardcoding pip, which failed on common macOS/Homebrew boxes.

InstallArgs now takes the project directory. It prefers VIRTUAL_ENV, then .venv/venv pip (absolute path, platform layout), then pip3 over pip on PATH. Setup never bootstraps pip. Missing tools, pip-less uv venvs, and PEP 668 externally-managed-environment refusals return a Failed result with next steps instead of a raw exec error. Successful bare pip installs warn when requirements.txt was not updated.

The wizard plan preview, dry-run, and done screen use the same resolved command and surface Warning.

^{Reviewed by Cursor Bugbot for commit c9f1d48. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit e4f6310. Configure here.}