Replies: 1 comment
-
My team is doing something similar in our pydantic implementation. We've found success with 2 general approaches. Approach 1: Make models compatible with V1 and V2This is more similar to what you're suggesting. This begins to break when doing fancy stuff, like custom types. Implementation starts having many logic branches >> we found that the benefit wasn't worth the return on this, sadly. Instead, we went with approach 2. Approach 2: Downshift to V1.Sanity purposes, it is easier to downshift to V1, and reference all pydantic entities from an upfront declaration. For example, in IS_PYDANTIC_VERSION_1: bool = ... # some logic
if IS_PYDANTIC_VERSION_1:
from pydantic import BaseModel
else:
from pydantic.v1 import BaseModel |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi folks! :)
Description
We have started to add support for pydantic v2 in our distributed MLops platform. A core challenge we are currently facing, is that pydantic is literally part of every single python package in our platform and used for various use cases:
Our core issue is, that we need to support both versions for an unknown period. That is mainly, because there are ML models that have been trained with pydantic v1 and need to be served with v1, while there might be new ML models trained with v2 that also need to be served with v2. At runtime, especially in our ML endpoints, we might have either v1 or v2 installed, and we need to be able to support both.
This brings us into a position where some components of our platform will need to be compatible with both versions for an unknown time (could be weeks, months, ...). This creates the need to provide a cross version compatibility layer that makes transition easier.
While we have been able to get most utilised pydantic features test and type safe cross version (using some sort of wrapper/adapter code), pydantic model configuration is a thing which still bothers us. This is because there might be hundreds/thousands of places where base models are persisted in code with different configuration settings (mutable or immutable, with aliasing or without, with extras or without, etc.).
To ease this transition, we have thought about creating cross version compatible mixin classes that can be requested to create configured pydantic models. This is somewhat the idea:
To make a model immutable, our customers could then just simply declare their models this way:
However, this becomes tricky with multiple inheritance. We have tried two possible approaches with v1, which both fail type checks with the pydantic mypy plugin
Approach No 1 (using Config classes)
Running mypy on this code fails
Approach No 2 (using class kwargs)
Running mypy on this code fails as well, albeit with different error messages
Does anyone know of a way to use multiple configuration mixin classes in pydantic v1 and have them pass mypy type checks?
System Details
mypy configuration
Beta Was this translation helpful? Give feedback.
All reactions