LangChain introduction and the 1.x package split

What you'll learn

• Explain why LangChain 1.0 split one package into four kinds of package.
• Name the package that holds each part of a chain: template, model and parser.
• Diagnose an old import from its exception class alone.
• Choose between moving an old class and replacing it.

T2.2 called the provider SDKs directly, and T3.1 and T3.2 wrote the prompts those calls send. This module wraps both in LangChain, the framework most notebooks in this course are written in.

The Larkspur Cloud support assistant has a script from an older LangChain tutorial. It imports LLMChain from langchain.chains, HumanMessage from langchain.schema and the prompt hub from langchain. On the course environment (langchain 1.4.7, langchain-core 1.7.0) the script stops on its first line. The old path has no shim that forwards it and no warning that names the new one.

The reason is a change in where code lives. Through the 0.x releases, the langchain package held the whole ecosystem: chains, agents, memory, retrievers, every provider integration and the prompt hub. Installing it pulled in all of that, and a break in any one integration could break the import. Version 1.0 split the surface by how fast each part changes and who owns it:

Table 1: The four kinds of package in LangChain 1.x.

Every other package builds on langchain-core:

Figure 1: The dependency direction. A partner package can change at its provider's pace without touching the base types.

The three parts of every chain

The first notebook already shows the shape every later chain keeps: a template, a model and a parser joined with LCEL's |. The notebook then grows it into a pipeline of three chains (details, then a one-sentence summary, then the summary's sentiment), each fed by the one before. Each of the three parts comes from a known package:

Figure 2: One chain, two sources. Only the model comes from outside langchain-core.

The model class comes from a partner package (langchain_openai.ChatOpenAI), or from init_chat_model in langchain when the provider is named in a string. Everything else in this module, the template classes, the message classes and all four output parsers, imports from langchain-core. T4.2 covers the pipe itself, and lessons 2 to 7 of T4.1 cover the three parts. Knowing where each class lives is half of a migration. The other half is reading the error when an old path fails.

Old code fails on 1.x in two different ways, and the exception class says what moved. We ran the notebook's import audit and the hub import on the course environment:

Table 2: The seven 0.x module paths the notebook audits, plus the hub. All seven raise ModuleNotFoundError; only the hub raises ImportError.

ModuleNotFoundError means the module is gone. ImportError means the package still exists and no longer exports the name. A third message looks similar and means something else: No module named 'langchain_classic' says the replacement package is not installed in this environment. Listing it in a requirements file is not the same as installing it. Declare it in the project's dependencies and sync.

Read the three messages in order:

Figure 3: Diagnosing an old import. Each "no" moves one question down.

The short paths that langchain keeps are aliases, not copies. langchain.messages.HumanMessage is langchain_core.messages.HumanMessage returns True on the course environment. The notebook reads a False as two LangChain installs on sys.path, a broken environment that no import change will fix.

Moved is not recommended

Memory is the one place where the moved class is the wrong answer. ConversationBufferMemory still imports from langchain_classic.memory, and the old app would run again after a one-line change. The 1.x replacement is a LangGraph checkpointer with a thread_id (T4.4, T10.1), which stores each conversation outside the process. We call the shortcut the moved-class migration: the import works, and the design it carries is the one 1.x retired. Retired chains are a milder case of the same thing. langchain_classic.chains still runs them, and T4.2 rewrites them as LCEL.

For the Larkspur script, the error classes give the order of work:

1. ModuleNotFoundError on langchain.schema: import HumanMessage from langchain_core.messages.
2. ModuleNotFoundError on langchain.chains: rewrite LLMChain as template, model and parser joined with |, which needs no classic package.
3. ImportError on hub: import it from langchain_classic, and add that package to the project's dependencies if the next error says it is missing.
4. Any conversation memory: move it to a checkpointer, not to langchain_classic.memory.

Key distinction: a ModuleNotFoundError names a path, an ImportError names a symbol. Fix the path for the first and the import source for the second.

Lesson 2 of T4.1 takes the middle part of Figure 2, the chat model, and shows what stays the same when its provider changes.

The code for this lesson is in these notebooks. Colab runs one in your browser: install the packages its first cell imports and set the API keys it reads. To run every notebook as written, clone the repository and use its uv environment.

• Version 1.0 split LangChain by pace of change. Prompts, messages, parsers and Runnable live in langchain-core, each provider in its own package, and retired chains and the hub in the frozen langchain-classic.
• Read the exception class. ModuleNotFoundError means the module moved, ImportError means the package no longer exports the name, and a missing langchain_classic means it is not installed.
• Not every old class should simply move. Replace conversation memory with a LangGraph checkpointer and a thread_id, and rewrite retired chains in LCEL.