Generative AI with LangChain, Second Edition: what the companion repository actually contains

What the repository is, and who the second edition targets

This is a book's code repository, not a framework. The README states plainly that it is the code for Generative AI with LangChain, Second Edition, published by Packt, written by Ben Auffarth and Leonid Kuligin. The subtitle on the cover is "Build production ready LLM applications and advanced agents using Python and LangGraph." The repository holds chapter directories, chapter1 through chapter9, plus a writing_assistant directory, and the top level carries a Dockerfile, a Makefile, requirements.txt, pyproject.toml, SETUP.md and langchain_ai.yaml.

The intended reader is a Python developer who has the book open next to the notebook. The README's key learnings list names the ground it covers: multi-agent systems with LangGraph, testing and evaluation frameworks, observability and monitoring, RAG with hybrid search and re-ranking, agents for software development and data analysis, and work with Google Gemini, Anthropic, Mistral, DeepSeek and OpenAI o3-mini. That list is a table of contents, not a feature set you install. If you do not own the book, you are reading source files whose surrounding argument lives elsewhere.

Four branches, four LangChain versions, and the cost of picking wrong

The most consequential thing in the README is the reader note about branches. There are four: v1, described as the latest migration with updates for LangChain v1.0 and 2026 model standards on Python 3.12+; second_edition, which corresponds to the second edition print and uses LangChain v0.3; softupdate, for the 2024 soft update against LangChain 0.1.13; and main, the original December 2023 version. The default branch is second_edition.

This is a real constraint rather than a footnote. LangChain changed its package layout substantially between 0.1 and 0.3, and again toward 1.0, and the requirements.txt on the second edition pins the 0.3 generation explicitly: langchain==0.3.17, langchain-core==0.3.63, langchain-community==0.3.16, langgraph==0.3.34. Notebook code written against that set will not simply run after an unpinned upgrade. The README also states the repository might not match every minor LangChain update, and that the aim is consistency rather than chasing each release. Treat that as the honest description of a book companion: it is pinned so the printed page stays true, and it will fall behind the ecosystem on purpose.

Installing the environment and running a first notebook

There are two documented paths. The Dockerfile builds from continuumio/miniconda3:23.9.0-0, installs pandoc, wget and build-essential, copies requirements.txt in, upgrades pip, installs a CPU build of torch from the PyTorch CPU index, then installs the requirements with --prefer-binary --no-cache-dir. It exposes port 8888 and its entrypoint is jupyter notebook with the notebook directory set to the working copy, bound to 0.0.0.0, with token and password disabled. A comment in the file notes that supporting streamlit would mean adding another EXPOSE, with 8501 as the example.

FROM continuumio/miniconda3:23.9.0-0
RUN apt-get update && apt-get install -y pandoc wget build-essential && rm -rf /var/lib/apt/lists/*
COPY requirements.txt .
RUN python -m pip install --upgrade pip && pip cache purge
RUN pip install torch>=1.11.0 --extra-index-url https://download.pytorch.org/whl/cpu
RUN pip install --prefer-binary --no-cache-dir -r requirements.txt
EXPOSE 8888
ENTRYPOINT ["jupyter", "notebook", "--notebook-dir=.", "--ip=0.0.0.0", "--allow-root", "--NotebookApp.token=''", "--NotebookApp.password=''"]

Building and running that image gives you a Jupyter server on port 8888 with the chapter notebooks already in the working directory. The token and password being switched off is convenient locally and a bad idea on any host reachable from outside your machine.

The alternative is a local install from the pinned requirements, which the repository ships at the top level:

pip install -r requirements.txt
jupyter notebook

The README does not spell out a virtualenv step, but requirements.txt pins exact versions for arxiv, datasets, duckduckgo_search, huggingface-hub, langchain and its provider packages, langsmith, streamlit, ray, rank_bm25 and wikipedia, so a dedicated environment is the only way to avoid colliding with whatever else is on your machine. Note the Python target: pyproject.toml configures ruff with target-version = "py311", while the README describes the v1 branch as Python 3.12+. The second edition branch and the v1 branch therefore assume different interpreters.

For a first real use, open the chapter notebooks in order. The Makefile gives a sense of where the code is expected to be exercised: its objects variable lists chat_with_retrieval/, data_science/, information_extraction/, monitoring_and_evaluation/, prompting/, question_answering/, search_engine/, software_development/, summarize/, webserver/ and writing_assistant/, and the typecheck target runs mypy over them. Those directory names describe the applications the book builds. Expect to supply your own API keys for whichever providers a notebook uses; the requirements file includes langchain-openai, langchain-anthropic, langchain-google-genai, langchain-google-vertexai, langchain_groq, langchain_mistralai, langchain-ollama and langchain_huggingface, and the README does not document where keys are read from.

Where the repository stops being the right tool

The chapter directories are Jupyter notebooks, and the repository's own lint configuration excludes notebooks from ruff entirely. That tells you what kind of code this is: exploratory, cell-by-cell, meant to be read alongside prose. Nothing in requirements.txt or pyproject.toml describes packaging this code as a distributable library, and there is no published package to depend on.

The pinned versions are the second failure mode. If you install requirements.txt on the second_edition branch you get langchain 0.3.17 and langgraph 0.3.34. Code you write today against a newer LangChain will not match the imports in these notebooks, and upgrading the pins in place will break cells that rely on the older APIs. The README's own commitment section says the repository might not match every minor LangChain update, so this is deliberate, not neglect.

Third, the Dockerfile installs the CPU build of torch from the PyTorch CPU wheel index. On a machine with a GPU you would remove that index option, as a comment in the file says. Out of the box, anything in the book that expects GPU acceleration will not get it.

Finally, the README does not document rollback, migration steps between branches, or how to move a notebook from one branch to another. If you need a supported upgrade path, this is not where you will find one.

How this differs from starting with LangGraph or LangChain directly

The obvious alternative is the upstream documentation and example set for LangChain and LangGraph themselves. The difference is one of shape rather than topic. Upstream docs are organized around the current API and are revised as that API moves; this repository is organized around nine printed chapters and is pinned to the versions those chapters were written against. Upstream will tell you the current way to build a graph. This repository will show you a multi-agent setup in the context of an argument about design patterns, with the surrounding explanation on paper.

A second alternative is a project template or starter kit, which gives you a working skeleton to modify. This repository does not do that. There is no scaffold command, no application entry point described in the README, and no deployment configuration beyond a Dockerfile whose entrypoint is Jupyter. You get notebooks and a book.

That distinction matters when you are choosing. If your goal is to ship a service this quarter, a template plus current upstream docs is the shorter route. If your goal is to understand why a LangGraph handoff or a hybrid-search retrieval pipeline is structured the way it is, the book's sequencing is the thing you cannot get from an API reference.

Licence, maintenance and what an upgrade actually costs

The repository is MIT licensed, and the LICENSE file sits at the top level. MIT is permissive: it lets you reuse the code with attribution and without a copyleft obligation on your own work. The book text itself is a separate commercial product from Packt, and the README points to a free DRM-free PDF for readers who already bought a print or Kindle copy, plus a separate graphic bundle of the colour figures. The MIT grant covers the code in the repository, not the prose. That is a distinction worth checking with whoever handles licensing at your organisation, since I am describing what the files say and not advising you on your situation.

The last push to the repository was on 2026-08-14, which is recent enough that the project is not dormant. The README states the companion repository is regularly updated to harmonise with LangChain developments, and also states it may not match every minor update. Both sentences are in the same commitment section, and they describe the same policy: updates arrive in batches, branch by branch, rather than continuously.

The upgrade cost follows from that. Moving from second_edition to v1 is not a version bump, it is a change of LangChain generation and, per the README, of Python baseline from the py311 target in pyproject.toml to 3.12+. You would be re-reading notebooks against a different API surface. Budget for that as a rewrite of your own code, not a dependency update.

Editorial conclusion

Adopt this repository if you own the second edition and want the notebooks that match its printed chapters, or if you want a working reference for LangGraph multi-agent patterns at LangChain 0.3. Do not adopt it as a dependency, as a starter template for a production service, or if you are already on LangChain v1.0, because the second_edition branch pins langchain==0.3.17 and the v1 branch exists for that migration. Before you start, verify which branch corresponds to your copy of the book, confirm the Python version your environment provides against the py311 target in pyproject.toml, and check that the model providers named in requirements.txt are ones you can actually reach.

Frequently asked questions

Official sources

1. benman1/generative_ai_with_langchain on GitHub
2. Issues
3. License: MIT
4. Project website
5. README