# Pins the scaffolded gate workflow's install to an exact, verified
# LiteLLM release, rather than whatever PyPI serves `pip install` that day --
# LiteLLM had a real supply-chain compromise (24 Mar 2026, 1.82.7/1.82.8).
# This exact pin is the real protection; pyproject.toml's own `<2.0` cap
# admits every 1.x patch on its own.
#
# 1.93.0 is the floor pyproject.toml's own comment names for Python 3.14
# support (declares Requires-Python >=3.10,<3.15), but it ships only a
# manylinux wheel plus a Rust (maturin) sdist -- pip must compile it from
# source on macOS, Windows or a musl runner, which is slow at best and
# fails outright with no Rust toolchain. 1.93.2 is the first >=1.93
# release with cp310-cp314 wheels for macOS (x86_64 + arm64), manylinux,
# musllinux and win_amd64 (confirmed against PyPI's published file list),
# so this one pin covers the whole 3.11-3.14 matrix on every platform
# `runs-on`/`gate-action` can target, rather than needing environment
# markers for two.
#
# This is an EXACT pin, not a hash lock. `pip install -c constraints.txt
# --require-hashes` needs a hash for every package in the resolved tree
# (not just this one), which in turn needs a network resolve to collect --
# unavailable where this file was written. Raise the pin alongside
# pyproject.toml's own litellm floor; never past its <2.0 cap, and never
# below 1.93.2 while 3.14 is supported, without re-verifying first (same
# wheel-availability check, not just the version bound).
# See tests/gate/test_workflows.py's
# test_the_two_vendored_constraints_files_are_byte_identical and
# test_the_vendored_litellm_pin_satisfies_pyprojects_own_range, which keep
# this file and gate-action/constraints.txt identical and check the pin
# against pyproject.toml's own specifier.
litellm==1.93.2
# Pinned for the same reason as litellm above -- a target launched via
# uvx/uv otherwise installs whatever uv PyPI serves that day.
uv==0.12.22
