Feedback request: Pydantic migration

[eyurtsev]

UPDATE 2024-08-01

1. We are looking tentatively at September for a full upgrade to pydantic 2. This will be a breaking release for langchain numbered 0.3.x. We will drop support for pydantic 1, but may continue supporting pydantic.v1 namespace from pydantic 2. You can track related PRs here)
2. Our tool APIs accept pydantic v2 objects now (see https://python.langchain.com/v0.2/docs/how_to/pydantic_compatibility/#1-passing-pydantic-objects-to-langchain-apis, requires langchain-core>=0.2.23). If using bind_tools or with_structured_output please consult the list above to see compatibility for the partner package you're using.

Pydantic Migration Feedback Request

We've previously announced that we're planning on dropping support for Pydantic 1 and migrating to Pydantic 2 (see #19339).

We need your input to determine which parts of this work should be prioritized.

We're aware of four main issues that arise when using Pydantic 2 with LangChain:

1: Using Pydantic 2 Objects to structure LLM outputs

SEE UPDATE ABOVE This issue has been resolved for a number of partner packages.

Oftentimes we use Pydantic Objects to structure LLM outputs. Most notably, we do this in with_structured_output, bind_tools and when specifying tool schema. Eg:

model.with_structured_outputs(Class) # this will break

See here for more details: #22782

2: Subclassing

If creating a custom tool or custom chat model, you can only use v1 features via the pydantic.v1 namespace (e.g., https://python.langchain.com/v0.1/docs/guides/development/pydantic_compatibility/).

3: Run-time validation has to be disabled for LangChain objects used inside Pydantic v2 models

e.g.,

from pydantic import BaseModel, SkipValidation

from langchain_openai import ChatOpenAI # <-- ChatOpenAI uses pydantic v1


class Foo(BaseModel): # <-- BaseModel is from Pydantic v2
    model: Annotated[ChatOpenAI, SkipValidation()]

Foo(model=ChatOpenAI(api_key="hello"))

4: LangServe cannot generate OpenAPI docs if running Pydantic 2

See: https://python.langchain.com/v0.2/docs/langserve/#pydantic

Our plan & ask

Our sense is that most of the issues are arising with issue number 1 above. We are therefor planning to prioritize a fix for that. We would love feedback on whether this is the case! Is this the biggest pain point? Are points 2&3 larger? Are there other things people are running into?

Thank you!

[pankajgarkoti]

model.with_structured_outputs(Class) # this will break

This to me is the most useful thing to come out of langchain for my use case. However, I realized a while ago that it doesn't work if I import BaseModel from the pydantic package and have to necessarily use langchain.pydantic_v1.

Would love if with_structured_output becomes better documented and highlighted as a first-class feature of langchain instead of just an experimental thing.

[eyurtsev]

We've released updates that resolves this issue across a number of partner packages, please consult this list: https://python.langchain.com/v0.2/docs/how_to/pydantic_compatibility/#1-passing-pydantic-objects-to-langchain-apis

[TimChild]

For myself, 2 and 3 are more frustrating.

1 would be nice, but since that's pretty low level I find it less frustrating to use v1 syntax to define the output format, and then move that data into my v2 schemas that include additional information anyway.

Points 2 and 3 show up when I am trying to do things that are a bit more complicated, and then I find it frustrating to also have to keep in mind the boundary between v1 and v2 objects, particularly with very simple models that aren't obviously taking advantage of new v2 features, but are already coupled to other v2 models within my codebase.

If the plan is to stop supporting v1 alltogether (which I think would be acceptable at this point given that I think most other libraries at least support working with v2 installed if not used), I would lean towards doing it all in one go, ideally with some migration scripts that help transition from v1 to v2.

[pasha-dektev]

Only using 1 - so 1

[eyurtsev]

We've released updates that resolves this issue across a number of partner packages, please consult this list: https://python.langchain.com/v0.2/docs/how_to/pydantic_compatibility/#1-passing-pydantic-objects-to-langchain-apis

[ZachHandley]

Honestly this is so far behind every other framework. Just upgrade everything. Had you done it before, when it was said it would be done, it probably wouldn't be something that had to be migrated. LangChain has been holding back my ecosystem for well over a year now.

[samuelcolvin]

@nfcampos we made a big effort to make migrating easy, and organizations big and small have migrated without too much trouble.

"no path"

Is just plain wrong:

• We vendor v1 inside v2
• We vendor .v1 inside v1 to make migrating easier
• We have shims for virtually every public attribute of v1

V1 was a victim of its own success when I was maintaining it in my spare time, and we had to break some stuff to make V2 better.

😞

[nfcampos]

@samuelcolvin

Im not saying you made migration hard (ie moving an app from using pydantic v1 to using pydantic v2, although for what it's worth it was quite an effort to migrate another app using pydantic and fastapi to v2, but that's a different convo)

I'm saying you made it hard for library authors to support our users having either v1 or v2 installed, using either v1 or v2 models being used in same codebase.

If there is some way to support this in our library I'd love to know, as that would make it much more likely we migrate to v2 anytime soon

[samuelcolvin]

What would you like us to do?

[eyurtsev]

Hi @samuelcolvin,

The biggest question for us is what's going to happen when pydantic 3 is released? Will that ship .v1 and .v2 namespaces with it? LangChain uses the pydantic.v1 namespace. If we upgrade to v2 or v3, it’s a breaking change for LangChain users that have customized components (e.g., via sub-classing). Can LangChain avoid following pydantic’s schedule for breaking changes?

Two improvements that would be great:

1. Improve error messages shown if mixing pydantic objects from v1, v2 namespaces (in any permutation)

from pydantic import BaseModel as BM2
from pydantic.v1 import BaseModel as BM1

class Bar(BM1):
    y: int
    
class Foo(BM2):
    x: Bar

Foo(x=Bar(y=5))

TypeError: BaseModel.validate() takes 2 positional arguments but 3 were given

Would ideally detect that a different namespace is used and alert the user on how to adjust the code.

2. Mixing features between v1 and v2 namespaces

It would be good if either features worked across namespaces or else users were alerted on errors.

from pydantic import BaseModel
from pydantic.v1 import root_validator

class Bar(BaseModel):
    y: int

    @root_validator
    def meow(cls, values):
        return values.

[samuelcolvin]

Sorry for the slow reply here.

@eyurtsev I'm sure we can do something about raising clearer error messages when v1 and v2 are accidentally used together, please create an issue on Pydantic.

Regarding V3, see pydantic/pydantic#10033 which I've at last gotten around to writing - TL;DR v3 should have minimal breaking changes, so it should be easy for libraries like FastAPI and Langchain to support both V2 and V3 at the same time.

[codekiln]

Just want to chime in and say 4 will likely hold us back, as a number of our developers make heavy use of the OpenAPI docs.

[gbaian10]

1 is the biggest problem.
4 made me completely give up using LangServe from the beginning.

[Ko-Ko-Kirk]

I hope that when upgrading to version 0.3, most of the code won't need to be modified or rewritten. Otherwise, I'm concerned that we might see another startup writing an article titled "Why We Quit LangChain." 🥹🥹

[eyurtsev]

You should expect to make modifications if you're sub-classing from langchain objects and are using Pydantic features that have changed between Pydantic 1 and Pydantic 2. See issue #2. To a lesser extent you may be affected by issue #3 if you're still using pydantic.v1 models internally.

You will need to upgrade your code base to pydantic 2. This upgrade can be done gradually (by first swapping to the v1 namespace), and afterwards upgrading to pydantic 2 proper. The actual migration from Pydantic 1 to 2 can get very involved if you're using a lot of internal features.

These changes stem from breaking changes made between pydantic 1 and pydantic 2, and unfortunately we don't have anyway of avoiding them.

If you're not relying on many pydantic features, the migration should be relatively uneventful.

How was your experience migration from LangChain 0.1 to 0.2?

[Ko-Ko-Kirk]

The experience upgrading from LangChain 0.1 to 0.2 was completely painless for me. The transition was smooth. I hope the LangChain team can consider retaining compatibility with Pydantic v1 for a while longer. Although I haven't relied heavily on Pydantic features 😂😂

BTW, I really love LangChain ❤️, and I think it has incredibly valuable in my projects. In fact, I even published a book on LangChain in Taiwan! LangChain Book in Taiwan.

[gbaian10]

My only problem is that when I upgrade and migrate using langchain-cli, I am forced to change it to pydantic v1. 😓

[eyurtsev]

@Ko-Ko-Kirk did you use langchain-cli for migration?

@gbaian10 could you explain what you mean by "I am forced to change it to pydantic v1. "?

[gbaian10]

@Ko-Ko-Kirk did you use langchain-cli for migration?

@gbaian10 could you explain what you mean by "I am forced to change it to pydantic v1. "?

Previously, I installed langchain-cli to help upgrade the code from v0.1 to v0.2, following the instructions on this page: https://python.langchain.com/v0.2/docs/versions/v0_2/

I recall that installing the CLI caused Pydantic to be downgraded to v1, possibly because Langserve only supported v1 in the past? Or maybe I'm mistaken.

However, it appears that this issue no longer exists.

[baskaryan]

v0.3 with Pydantic 2 support is out! #26544

[JoshuaC215]

Really happy about this launch! Created some major simplification and improvements for my project. Thank you LangChain team!!