Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix [Bug]: Dependency pinning in commit #5f63873 — intentional change? [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25280•Fetched 2026-04-08 03:02:15
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
1
Author
HarryEHHarryEH
Participants
HarryEHHarryEH
Timeline (top)
labeled ×2

Root Cause

Using CPython 3.14.3 interpreter at: /opt/containerbase/tools/python/3.14.3/bin/python3
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version == '3.14.3' and sys_platform == 'win32'):
  ╰─▶ Because litellm==1.83.3 depends on python-dotenv==1.0.1 and
      api depends on litellm[proxy]==1.83.3, we can conclude
      that api depends on python-dotenv==1.0.1.
      And because api depends on python-dotenv==1.2.2 and
      your workspace requires api, we can conclude that your
      workspace's requirements are unsatisfiable.

PR fix notes

PR #24905: [Infra] Pin All Docker Build Dependencies

Description (problem / solution / changelog)

Summary

Problem

After the LiteLLM supply chain attacks, Docker builds pulled unpinned dependencies — base images, pip packages, npm packages, and transitive deps could silently change between builds. Additionally, aioboto3 was listed in requirements.txt for async SageMaker calls but was never actually imported — the codebase uses httpx + botocore SigV4 instead. Its presence caused an unresolvable botocore version conflict with boto3, requiring grep -v / --no-deps workarounds across all Dockerfiles and ~20 CI job definitions.

Fix

Pin every dependency across all Docker builds to exact versions verified against known-good v1.83.0-nightly images. Remove the unused aioboto3 dependency and all associated botocore conflict workarounds. Bump cryptography in pyproject.toml to 46.0.5 to match Docker and address GHSA-r6ph-v2qm-q3c2.

Changes

aioboto3 removal

  • Removed aioboto3==15.5.0 and its transitive deps (aioitertools, wrapt) from requirements.txt
  • Removed grep -v '^aioboto3' + pip install --no-deps workarounds from all Dockerfiles (main, database, alpine, dev, non_root) and all CI jobs in .circleci/config.yml
  • Removed aioboto3, aioitertools, wrapt from liccheck.ini authorized licenses
  • Simplified boto3 comment (no longer needs "compatible with aioboto3" note)

Python dependencies

  • requirements.txt: All 84+ entries now use == exact pins, including transitive deps (aiofiles, colorlog, grpc-google-iam-v1, hf-xet, requests-toolbelt)
  • pyproject.toml: All production and dev dependencies pinned to exact versions; cryptography bumped from 43.0.3 to 46.0.5 (GHSA-r6ph-v2qm-q3c2)
  • Collapsed redundant grpcio python-version markers into single entry in both requirements.txt and pyproject.toml
  • scripts/health_check/health_check_requirements.txt: Pinned to match main
  • docker/build_from_pip/requirements.txt: Pinned, updated from stale dev version

Docker base images — pinned to @sha256 digests:

  • cgr.dev/chainguard/wolfi-base (main, database, non_root)
  • python:3.13-slim (dev, health_check — upgraded from 3.11-slim to resolve critical vuln)
  • python:3.11-alpine (alpine)
  • python:3.13-alpine (build_from_pip)
  • ghcr.io/berriai/litellm:main-latest (deploy)

Build tools

  • npm@latest → [email protected] in all Dockerfiles
  • pip install build → build==1.4.2 in all Dockerfiles
  • pip install --upgrade pip → pip==26.0.1 in all Dockerfiles
  • aurelio-sdk install uses --no-deps to prevent transitive dep floating

Dockerfile fixes

  • Dockerfile.non_root: Bypass .npmrc during UI build (min-release-age incompatible with npm 11); fixed misleading comment about --userconfig /dev/null
  • Dockerfile.custom_ui: Added --no-install-recommends to apt-get install
  • Dockerfile.health_check: Added non-root user, HEALTHCHECK instruction, upgraded to python:3.13-slim

Testing

  • Built all 3 production Docker images locally (litellm, database, non_root) — all pass cleanly without the grep -v workaround
  • Confirmed zero imports of aioboto3 or aiobotocore in the Python source
  • Extracted pip freeze from each image and diffed against v1.83.0-nightly baseline
  • Result: zero version drift (only litellm wheel hash differs due to local build)

Type

🚄 Infrastructure

Changed files

  • .circleci/config.yml (modified, +68/-72)
  • .circleci/requirements.txt (modified, +5/-5)
  • Dockerfile (modified, +5/-5)
  • deploy/Dockerfile.ghcr_base (modified, +1/-1)
  • docker/Dockerfile.alpine (modified, +5/-5)
  • docker/Dockerfile.custom_ui (modified, +3/-2)
  • docker/Dockerfile.database (modified, +5/-5)
  • docker/Dockerfile.dev (modified, +5/-5)
  • docker/Dockerfile.health_check (modified, +9/-1)
  • docker/Dockerfile.non_root (modified, +11/-5)
  • docker/build_from_pip/Dockerfile.build_from_pip (modified, +7/-9)
  • docker/build_from_pip/requirements.txt (modified, +5/-5)
  • docker/install_auto_router.sh (modified, +1/-1)
  • poetry.lock (modified, +916/-888)
  • pyproject.toml (modified, +85/-89)
  • requirements.txt (modified, +39/-34)
  • scripts/health_check/health_check_requirements.txt (modified, +2/-2)
  • tests/code_coverage_tests/liccheck.ini (modified, +1/-1)
  • tests/test_litellm/proxy/middleware/test_in_flight_requests_middleware.py (modified, +1/-1)
  • tests/test_litellm/router_strategy/test_base_routing_strategy.py (modified, +4/-3)

Code Example

Using CPython 3.14.3 interpreter at: /opt/containerbase/tools/python/3.14.3/bin/python3
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version == '3.14.3' and sys_platform == 'win32'):
  ╰─▶ Because litellm==1.83.3 depends on python-dotenv==1.0.1 and
      api depends on litellm[proxy]==1.83.3, we can conclude
      that api depends on python-dotenv==1.0.1.
      And because api depends on python-dotenv==1.2.2 and
      your workspace requires api, we can conclude that your
      workspace's requirements are unsatisfiable.
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

This is a follow-up to #25210. I noticed that commit 5f63873 pins every dependency to an exact version. I wanted to flag this in case it wasn't intentional. If litellm is still intended to be consumed as a library, exact-pinning in the package metadata can cause dependency conflicts for downstream users. The general best practice for libraries is to use loose constraints (e.g., >={version}) and test against a range of dependency versions in CI. Exact pinning is typically reserved for pure application deployments, where a lockfile can handle transitive dependency locking and ensure reproducible Docker builds. You can still use the lockfile here to have reproducible builds for the images. Could you clarify whether this reflects a deliberate shift in how litellm is meant to be distributed? If it was unintentional, it would be great to revert to flexible version specifiers so that library consumers aren't impacted. Thanks for all the work on litellm — happy to help or discuss further!

Steps to Reproduce

  1. uv add litellm then add any dependency that is pinned not at the pinned version

Relevant log output

Using CPython 3.14.3 interpreter at: /opt/containerbase/tools/python/3.14.3/bin/python3
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version == '3.14.3' and sys_platform == 'win32'):
  ╰─▶ Because litellm==1.83.3 depends on python-dotenv==1.0.1 and
      api depends on litellm[proxy]==1.83.3, we can conclude
      that api depends on python-dotenv==1.0.1.
      And because api depends on python-dotenv==1.2.2 and
      your workspace requires api, we can conclude that your
      workspace's requirements are unsatisfiable.

What part of LiteLLM is this about?

SDK (litellm Python package)

What LiteLLM version are you on ?

V1.83.3

Twitter / LinkedIn details

https://linkedin.com/in/heh

extent analysis

TL;DR

Revert to flexible version specifiers in the package metadata to avoid dependency conflicts for downstream users.

Guidance

  • Review the commit history to determine if the exact pinning of dependencies was intentional, and consider reverting to loose constraints (e.g., >= {version}) to allow for more flexibility.
  • Test the library against a range of dependency versions in CI to ensure compatibility and catch potential issues early.
  • Use a lockfile to ensure reproducible builds for Docker images, while still allowing for flexible version specifiers in the package metadata.
  • Consider the trade-offs between exact pinning (suitable for application deployments) and loose constraints (suitable for libraries) when deciding on a versioning strategy.

Example

No code snippet is provided as it is not clearly supported by the issue.

Notes

The issue highlights the importance of considering the intended use case of the library (in this case, litellm) when deciding on a versioning strategy. Exact pinning may be suitable for application deployments, but can cause issues for downstream users of a library.

Recommendation

Apply a workaround by reverting to flexible version specifiers to avoid dependency conflicts and ensure compatibility with a range of dependency versions. This approach allows for more flexibility and is suitable for libraries intended to be consumed by downstream users.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#dependency conflict#container setup#orchestration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - ✅(Solved) Fix [Bug]: Dependency pinning in commit #5f63873 — intentional change? [1 pull requests, 1 participants]