litellm - ✅(Solved) Fix [Bug]: python-dotenv pinned to ==1.0.1 since v1.83.1 causes dependency conflicts for library consumers [2 pull requests, 1 comments, 2 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#25210Fetched 2026-04-08 02:53:06
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
2
Author
Timeline (top)
cross-referenced ×2commented ×1referenced ×1

Root Cause

× No solution found when resolving dependencies:
╰─▶ Because fastmcp==3.2.0 depends on python-dotenv>=1.1.0 and
    litellm==1.83.3 depends on python-dotenv==1.0.1, we can conclude that
    litellm==1.83.3 and fastmcp[tasks]==3.2.0 are incompatible.

PR fix notes

PR #25231: fix: relax python-dotenv pin from ==1.0.1 to >=1.0.1

Description (problem / solution / changelog)

Summary

Relaxes the python-dotenv dependency pin in pyproject.toml from exact ==1.0.1 to lower-bounded >=1.0.1.

Motivation

The exact pin introduced in v1.83.1 makes litellm uninstallable alongside any package requiring python-dotenv>=1.1.0 (e.g. fastmcp[tasks]==3.2.0):

× No solution found when resolving dependencies:
╰─▶ Because fastmcp==3.2.0 depends on python-dotenv>=1.1.0 and
    litellm==1.83.3 depends on python-dotenv==1.0.1, we can conclude that
    litellm==1.83.3 and fastmcp[tasks]==3.2.0 are incompatible.

Exact pins in published package metadata propagate to every consumer's resolver. Reproducible builds should use lockfiles (poetry.lock), not exact pins in pyproject.toml.

Changes

  • pyproject.toml: Changed python-dotenv = "1.0.1" to python-dotenv = ">=1.0.1"

Testing

No behavioral change — this only affects dependency resolution. Existing tests are unaffected.

Disclaimer

AI agents (Claude Code) assisted with this contribution.

Fixes #25210

Changed files

  • pyproject.toml (modified, +1/-1)

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 buildbuild==1.4.2 in all Dockerfiles
  • pip install --upgrade pippip==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

× No solution found when resolving dependencies:
╰─▶ Because fastmcp==3.2.0 depends on python-dotenv>=1.1.0 and
    litellm==1.83.3 depends on python-dotenv==1.0.1, we can conclude that
    litellm==1.83.3 and fastmcp[tasks]==3.2.0 are incompatible.
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?

Since litellm==1.83.1, the python-dotenv dependency changed from >=0.2.0 to an exact pin ==1.0.1 in pyproject.toml (commit 5f63873d). This makes litellm uninstallable alongside any library that requires python-dotenv>=1.1.0 (e.g. fastmcp[tasks]==3.2.0).

Exact pins in published package metadata propagate to every consumer's resolver — reproducible Docker builds should use a lockfile instead.

Steps to Reproduce

  1. uv add litellm==1.83.3 "fastmcp[tasks]==3.2.0"
  2. Resolution fails immediately

Relevant log output

× No solution found when resolving dependencies:
╰─▶ Because fastmcp==3.2.0 depends on python-dotenv>=1.1.0 and
    litellm==1.83.3 depends on python-dotenv==1.0.1, we can conclude that
    litellm==1.83.3 and fastmcp[tasks]==3.2.0 are incompatible.

What part of LiteLLM is this about?

SDK (litellm Python package)

What LiteLLM version are you on ?

1.83.1, 1.83.2, 1.83.3

Twitter / LinkedIn details

No response

extent analysis

TL;DR

Use a version of litellm that does not have an exact pin on python-dotenv or use a lockfile for reproducible Docker builds to avoid dependency conflicts.

Guidance

  • The issue arises from the exact pin ==1.0.1 on python-dotenv in litellm's pyproject.toml, which conflicts with other libraries requiring python-dotenv>=1.1.0.
  • To mitigate this, consider using a version of litellm prior to 1.83.1 where the dependency was >=0.2.0, allowing for more flexibility in resolving dependencies.
  • Using a lockfile for Docker builds can help ensure reproducibility and manage dependencies more effectively, potentially avoiding such conflicts.
  • If possible, updating fastmcp to a version that is compatible with python-dotenv==1.0.1 could also resolve the issue, though this might not be feasible depending on the requirements of your project.

Example

No specific code example is provided as the issue is related to dependency management rather than code implementation.

Notes

This solution assumes that downgrading litellm or managing dependencies through a lockfile is feasible and does not introduce other compatibility issues. The exact approach may vary depending on the specific requirements and constraints of the project.

Recommendation

Apply a workaround by using a lockfile for reproducible Docker builds to manage dependencies effectively, as this approach does not require downgrading packages and can be adapted to various project requirements.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING