Working with Pydantic v1 while having v2 installed

[slafs]

This is a continuation of a topic introduced in #9709 (comment) as requested by @Kludex. I've chosen the "Show and tell" category as the (lack of) template seems better for this discussion.

In the original thread I've asked if there's a way to work with pydantic v1 while having v2 installed:

Pydantic v2 ships the latest version of v1 for easier migration, so the pattern is to work with v1 via things like from pydantic.v1 import BaseModel etc. while having v2 installed.

Currently, this approach doesn't seem to work with FastAPI 0.100.0 and the following snippet:

from fastapi import FastAPI

from pydantic.v1 import BaseModel


class Model(BaseModel):
    foo: str = "foo"
    bar: int = 2


app = FastAPI()


@app.get("/")
def root(model: Model) -> Model:
    return model

produces the following error:

Traceback (most recent call last):
  File ".../fiddles/fastapi_pydantic_v1_on_v2.py", line 15, in <module>
    def root(model: Model) -> Model:
  File ".../lib/python3.10/site-packages/fastapi/routing.py", line 706, in decorator
    self.add_api_route(
  File ".../lib/python3.10/site-packages/fastapi/routing.py", line 645, in add_api_route
    route = route_class(
  File ".../lib/python3.10/site-packages/fastapi/routing.py", line 448, in __init__
    self.response_field = create_response_field(
  File ".../lib/python3.10/site-packages/fastapi/utils.py", line 101, in create_response_field
    raise fastapi.exceptions.FastAPIError(
fastapi.exceptions.FastAPIError: Invalid args for response field! Hint: check that <class '__main__.Model'> is a valid Pydantic field type. If you are using a return type annotation that is not a valid Pydantic field (e.g. Union[Response, dict, None]) you can disable generating the response model from the type annotation with the path operation decorator parameter response_model=None. Read more: https://fastapi.tiangolo.com/tutorial/response-model/

Switching from pydantic.v1 to just pydantic (v2) obviously works.

I'm seeing there's fastapi._compat module and PYDANTIC_V2 var, but I'm not sure if that's the right direction.

For reference, installed versions:

fastapi==0.100.0
pydantic==2.0.3
pydantic_core==2.3.0

---

Now... that being said, I'm not even sure if this would be helpful to anyone even if FastAPI did support it. My initial thought was that this would ease the migration, but the reality seems more complicated. E.g. models are used by other models and even Pydantic itself doesn't support mixing v1 and v2 together. So given that the cost of figuring out the plan for the gradual migration seems comparable with doing the whole migration at once (at least for us).

Maybe it would be useful if people commented on their intended use case and see if that's actually a feature that's needed/wanted.

[chbndrhnns]

Well, I expect v1 models to work out of the box based on the comment on https://fastapi.tiangolo.com/release-notes/?h=v1#01000:

This version of FastAPI still supports Pydantic v1. And although Pydantic v1 will be deprecated at some point, ti will still be supported for a while.

On my use case, I'd like to be able to migrate models one by one while my system is still running.

[estarfoo]

I came across this issue in the context of collerek/ormar#1115. The behaviour in 0.100, with the PYDANTIC_V2 switch, excludes any upgrade path via pydantic.v1 imports, which seems to have been intended in Pydantic.

The logic around the various references to PYDANTIC_V2 in the code mostly seems to happen where there is a BaseModel instance nearby. Would it maybe suffice to check, in each place, whether (PYDANTIC_V2 and not type(obj) is V1_BaseModel), given import pydantic.v1.BaseModel as V1_BaseModel, before handling the model as V2-based?

(Would anyone need a fastapi.openapi.models.v1 in that case? Outside of fastapi._compat, that’s most of the places where the distinction is currently being made.)

[chbndrhnns]

I gave it a try at #10223 to support v1 models in request and response body.

[HammadB]

I would really expect this to work, we are running into it here chroma-core/chroma#893 (comment)

[o-fedorov]

Hi. For a response model based on pydantic.v1.BaseModel we've run into a similar issue, but this time it is TypeError:

  File ".../lib/python3.10/site-packages/fastapi/_compat.py", line 125, in validate
    self._type_adapter.validate_python(value, from_attributes=True),
  File ".../lib/python3.10/site-packages/pydantic/type_adapter.py", line 283, in validate_python
    return self.validator.validate_python(__object, strict=strict, from_attributes=from_attributes, context=context)
TypeError: BaseModel.validate() takes 2 positional arguments but 3 were given

fastapi==0.103.2
pydantic==2.4.2
pydantic_core==2.10.1

[ravi-kumar-pilla]

Hi @o-fedorov , I am encountering the same issue. Were you able to resolve this ? Thank you

[flinz]

@ravi-kumar-pilla @o-fedorov I am hitting the same error, after updating to pydantic 2.
I am at pydantic==2.6.0 and fastapi==0.109.2
Were you able to track down the origin of this?

[chbndrhnns]

You could give this PR a try: https://github.com/tiangolo/fastapi/pull/10223/files

[o-fedorov]

@flinz I ended up completely migrating to Pydantic v2, so unfortunately I can’t help with it anymore

[Kludex]

Let's follow it on #10360. No confirmation needed.