fix(install): pass an explicit Python version request to uv tool install

[tin-berri]

TLDR

Problem this solves:

• CLI installer fails on stock macOS (system Python 3.9)
• Default PyPI path silently installs stale litellm 1.83.9 instead

How it solves it:

• uv tool install now requests Python >=3.10,<3.15 explicitly
• Compatible system Pythons still reused; managed one downloaded otherwise

Relevant issues

• uv tool install picks an interpreter before resolving, so with no --python request stock macOS Python 3.9.6 satisfies the unconstrained request and resolution then fails against litellm's requires-python = ">=3.10, <3.15" instead of downloading a managed Python
• Reported by a user running the CLI installer on a stock Mac; the manual fallback command printed by the error message reproduced the same failure, so it now carries the flag too
• The same invocation exists in both scripts/install-cli.sh and scripts/install.sh; both are fixed identically

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
  • 73 of 74 checks pass; the only red is osv-scan, which currently fails on every branch (gitpython and brace-expansion lockfile CVEs that predate this PR and are untouched by it)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Screenshots / Proof of Fix

All runs simulate a stock Mac: fresh HOME, PATH=/usr/bin:/bin:/usr/sbin:/sbin so the only interpreter uv can discover is /usr/bin/python3 (3.9.6), and LITELLM_CLI_REF=litellm_internal_staging

Before, at commit 2412326 (staging head, unfixed):

$ env -i HOME="$(mktemp -d)" PATH="/usr/bin:/bin:/usr/sbin:/sbin" \
    LITELLM_CLI_REF=litellm_internal_staging sh scripts/install-cli.sh
  Installing litellm[cli] from litellm_internal_staging…
    Updated https://github.com/BerriAI/litellm.git (24123269ccb76f36298a2457589f08bd3141072c)
  × No solution found when resolving dependencies:
  ╰─▶ Because only litellm[cli]==1.95.0 is available and the current Python
      version (3.9.6) does not satisfy Python>=3.10,<3.15, we can conclude
      that all versions of litellm[cli] cannot be used.
      And because you require litellm[cli], we can conclude that your
      requirements are unsatisfiable.
  Error: uv tool install failed. Try manually: .../uv tool install 'litellm[cli] @ git+https://github.com/BerriAI/litellm.git@litellm_internal_staging'

scripts/install.sh fails identically with litellm[proxy]

After, at commit b089992 (fixed), same environment:

$ env -i HOME="$(mktemp -d)" PATH="/usr/bin:/bin:/usr/sbin:/sbin" \
    LITELLM_CLI_REF=litellm_internal_staging sh scripts/install-cli.sh
  Installing litellm[cli] from litellm_internal_staging…
Downloading cpython-3.14.3-macos-aarch64-none (download) (17.3MiB)
Installed 3 executables: lite, litellm, litellm-proxy
  ✔ LiteLLM CLI installed
  Version: 1.95.0
$ echo $?
0

System Python reuse still works at b089992 (same run with /opt/homebrew/bin prepended to PATH): no cpython download happens, ~/.local/share/uv/python is never created, and the tool venv's pyvenv.cfg shows home = /opt/homebrew/opt/python@3.14/bin with version_info = 3.14.5

scripts/install.sh in the stock environment at b089992 downloads cpython-3.14.3 the same way and reaches ✔ LiteLLM installed with Installed 3 executables: lite, litellm, litellm-proxy (that run then stops at the script's pre-existing interactive --setup prompt, which needs a real terminal and is unrelated to this change)

Type

🐛 Bug Fix

Changes

• Add --python '>=3.10,<3.15' to the uv tool install invocation in scripts/install-cli.sh and scripts/install.sh
• Add the same flag to the manual fallback command in each die message, which previously suggested a command that reproduced the failure
• Rewrite the comment that claimed uv honours requires-python on its own; uv selects the interpreter before resolving, so it does not

The range duplicates requires-python from pyproject.toml because a curl-to-sh bootstrap has nothing on disk to read it from; the comment marks it keep-in-sync. Without the explicit request, the default PyPI path fails worse than the git path: uv quietly resolves the newest release whose metadata admits Python 3.9, which today installs litellm 1.83.9 instead of 1.93.0

There is no test harness for scripts/*.sh and CI does not execute these scripts, so the proof above is live installer runs rather than unit tests

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

---

Note

Low Risk
Changes are limited to bootstrap shell installers and error-message hints; no proxy, auth, or application runtime code is touched.

Overview
Fixes curl-to-sh installs on hosts where the only discoverable Python is too old (e.g. stock macOS 3.9) by passing --python '>=3.10,<3.15' to uv tool install in scripts/install-cli.sh and scripts/install.sh, matching requires-python in pyproject.toml.

Without that flag, uv picks an interpreter before dependency resolution, so 3.9 can be selected and install fails—or on the default PyPI path, an older litellm that still allows 3.9 can be installed. --python-preference system is unchanged, so a compatible system Python is still reused when available.

Comments are updated to document the behavior, and the manual retry text in each die message includes the same --python flag.

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

[greptile-apps]

Greptile Summary

This PR aligns both shell installers with LiteLLM’s supported Python range.

• Adds an explicit >=3.10,<3.15 interpreter request to both uv tool install commands.
• Updates both manual fallback commands with the same interpreter request.
• Corrects comments describing uv’s interpreter-selection behavior.

Confidence Score: 5/5

The PR appears safe to merge, with both installer paths consistently requesting a supported Python interpreter.

The pinned uv version supports ranged Python requests, the new range matches the project’s current Python requirement, and system-preferred selection can fall back to a managed interpreter when necessary.

Important Files Changed

Filename	Overview
scripts/install-cli.sh	Adds a valid Python range matching project metadata to CLI installation and fallback commands; no actionable issue found.
scripts/install.sh	Applies the same compatible interpreter selection fix to the proxy installer; no actionable issue found.

_{Reviews (1): Last reviewed commit: "fix(install): pass an explicit Python ve..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[tin-berri]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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