How to create working requirements.txt for latest LangChain ecosystem packages?

Other Questions langsmith
1

I’m trying to set up a fresh Python 3.12 project with modern versions of LangChain and related packages. I want to use these specific package versions:

langchain==0.3.20
langchain-anthropic==0.3.9
langchain-cli==0.0.35
langchain-community==0.3.19
langchain-core==0.3.41
langchain-experimental==0.0.37
langchain-fireworks==0.2.7
langchain-openai==0.3.5
langchain-text-splitters==0.3.6
langcorn==0.0.22
langgraph==0.3.5
langgraph-api==0.0.27
langgraph-checkpoint==2.0.16
langgraph-cli==0.1.74
langgraph-prebuilt==0.1.1
langgraph-sdk==0.1.53
langserve==0.3.1
langsmith==0.3.11

But when I run pip install or uv pip install, I keep getting dependency conflicts. The main issues are:

  • Pydantic version clash: langchain==0.3.20 needs pydantic>=2.7.4 but langcorn==0.0.22 wants pydantic<2.0.0
  • sse-starlette mismatch: langgraph-api==0.0.27 needs sse-starlette>=2.1.0 while langserve==0.3.1 wants sse-starlette<2.0.0
  • Langcorn compatibility: No langcorn version seems to work with langchain==0.3.20

I’ve tried loosening version constraints but each fix creates new problems. Has anyone successfully created a working requirements file with current LangChain ecosystem packages? Should I give up on this exact combination?

2

Yeah, those version conflicts are totally expected with that combo. I spent weeks last year debugging the same mess when upgrading production. You’re mixing packages from different release cycles - that’s the core issue. Langcorn basically died around pydantic 1.x while everything else kept moving. The sse-starlette conflict? Langserve and langgraph-api never coordinated their dependency updates. Here’s what worked for me: start with minimal core packages, then add others one by one while testing. Use pip-tools to generate locked versions that actually resolve. Try conda instead of pip for initial setup - conda’s dependency resolver crushes pip’s when handling these conflicts. I’ve had good luck with conda-forge channel for LangChain stuff. Another option: use Docker with a known working base image. LangChain has official Docker images with pre-resolved dependencies you can extend from instead of building from scratch. Reality check - keeping exact versions across 18 interconnected packages is nearly impossible. Focus on what you actually need instead of installing the entire ecosystem.

3

Just use uv’s resolver with --resolution=highest - it handles conflicts way better than pip. Add --prerelease=allow too since some langchain packages have prereleases that fix dependency issues. I got a similar setup working by letting uv pick compatible versions instead of forcing exact ones. Your version pins are from different months so they’re never gonna work together.

4

Been wrestling with LangChain dependencies for months at work and honestly, those exact versions you listed are basically impossible to get working together.

The langcorn issue is the real killer - it’s stuck on pydantic 1.x while everything else moved to 2.x ages ago. We ran into this exact problem on three different projects.

Here’s what actually works in production:

Drop langcorn completely. Use FastAPI with langserve directly - does the same job without the pydantic nightmare.

Pin these core versions that play nice:

langchain==0.3.20
langchain-core==0.3.41  
langchain-openai==0.3.5
langchain-anthropic==0.3.9
langsmith==0.3.11
langgraph==0.3.5
langserve==0.3.1

Skip the experimental and CLI packages unless you absolutely need them. Add other packages one by one and test.

For sse-starlette, let the packages resolve it themselves. Don’t pin that version.

We ended up with about 8 LangChain packages instead of 18. Works fine and deploys without issues.

The brutal truth? The LangChain ecosystem changes too fast for tight version pinning. Pick your core 5-6 packages and let dependencies float within major versions.

5

Dependency hell with LangChain packages is brutal - I’ve been there countless times. What you’re hitting is classic version conflict stuff. These packages just weren’t built to play nice together at those exact versions.

But here’s what I’d do: step back and ask why you need all 18 packages anyway.

Usually when I see setups like yours, people are building complex AI workflows - multiple steps, different models, data processing, integrations. That’s exactly why I switched to Latenode.

Instead of wrestling with 18 packages and their conflicts, you build your LangChain workflow visually. Connect OpenAI, Anthropic, or Fireworks models right through the interface. Handle text splitting, vector storage, API serving - no package version nightmares.

I rebuilt our entire AI pipeline this way and cut about 200 lines of dependency management code. No more requirements.txt headaches. No more version conflicts when teammates pull the project.

Workflow runs in the cloud so your local environment stays clean. Just call the endpoint when you need results.

Try building your LangChain workflow there instead: https://latenode.com

6

Yeah, those dependency conflicts are just part of dealing with LangChain’s ecosystem. I ran into the same mess migrating our AI pipeline to those versions last month. You’re basically trying to use packages released at different times with incompatible dependencies.

Quickest fix I found: use Python 3.11 instead of 3.12. Some packages still have broken wheel builds for the newest Python version. Then use pip with --force-reinstall and --no-deps to install core packages first, then add dependencies manually.

Or try poetry instead of pip/uv. Poetry’s dependency resolver is way more aggressive at finding compatible versions. Just create a fresh pyproject.toml and let poetry figure out the constraints instead of forcing exact pins.

If you really need those exact versions, split things into separate virtual environments - one for core langchain, another for langgraph, etc. Actually better architecture anyway since these packages are massive.