In case it helps, I started PR about that:
#10223

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.

It seems people have been primarily doing that on #10223 and in issues opened against a heap of other projects (see above).
In short, not supporting the pydantic.v1 models completely blocks codebases that can't be upgraded all in one go to pydantic v2 (not practical in larger codebases, and the bump-pydantic tool misses many issues), which prevents people either from upgrading to pydantic v2 (which, at least based on its docs, seems like a solid improvement on v1) or keeps people on old versions of fastapi.

It also means that FastAPI doesn't really support pydantic v1 as indicated here. Specifically, it doesn't really support pydantic v2, since the backwards compatibility with pydantic v1 models is an important feature of that version allowing progressive upgrades.

Unfortunately that PR, though well-intentioned, appears to be abandoned. It's a bit lacking in detail as to what's left to be done or why it's not ready to merge, so it seems unlikely anyone'll be able to pick it up either - which given the amount of people asking about its status might otherwise have happened, though I'm under no illusion that it's much easier to ask about progress than to act on it yourself 😄

Unfortunately that PR, though well-intentioned, appears to be abandoned.

If you talk about PR #10223, it was complete IMO at the time of creation but sadly never got any response from @tiangolo.
I am willing to rebase it but not without feedback.

@tiangolo Any update on this issue??

Any way of getting some visibility here? It’s currently very hard to migrate for large code bases.

Joining the thread as well, I'm WIP updating from Pydantic V1 to V2 on a massive code base with dozens of FastAPI routes and hundreds of models. I use the "from pydantic.v1 import BaseModel" approach, however I have failures to generate OpenApi schema using FastAPI "get_openapi" utility since the schema generation fails when encountering a field with Pydantic V1 @validator decorator which is treated as a field instead of being ignored by the schema generator.

A good compromise might be if the pydantic v1 vs v2 logic was applied per APIRouter.
Each router can use either Pydantic V1 models or V2 models, but not use both simultaneously.

Devs with a large code base can then migrate per router (and, if need be, break up their app to use multiple routers).

This assumes that implementing this at the APIRouter level is easier/more maintainable.

Any news about this? I thought that i could easily apply fastapi and pydantic v2 upgrade but this totally blocks me.

Any update? It's making it very difficult to migrate large codebases to Pydantic v2.