Upgrade to Pydantic v2

[jaykv]

This will have to be tested more thoroughly of course, but I hope this is a good start to move towards pydantic v2 :)

Changes:

• New BaseModel method names, decorators, and config dict:
  • model.parse_obj -> model.model_validate
  • model.dict -> model.model_dump(mode="json")
  • @root_validator -> @model_validator
  • @validator -> @field_validator
  • parse_raw(raw_stuff) -> model_validate(json.loads(raw_stuff))
  • schema -> model_json_schema
  • json -> model_dump_json
  • class Config: ... -> model_config = ConfigDict(...)
• BaseModel subclasses using __root__ switched to subclass RootModel with root annotation
• New fields for ValidationErrorElement: input and url
• Updated custom type definition for BaseFile (thanks to flask-openapi3's implementation)
• Response on ValidationError updated to use err.json(indent=2) instead of jsonify(err.errors()) to avoid TypeError: _ is not JSONSerializable errors from the new input field (indent=2 to keep response consistent to current)
• Update model schema definitions key from definitions -> $defs
• req_validation_error.model.__name__ -> req_validation_error.title
• pydantic.EmailStr.validate -> pydantic.validate_email

[yedpodtrzitko]

Suggested change

	"pydantic-settings"
	"pydantic-settings",

[yedpodtrzitko]

Suggested change

	"pydantic-settings"
	"pydantic-settings",

[kemingy]

Thanks for your contribution.

Pydantic v2 has too many breaking changes that lots of 3rd libraries are not able to upgrade in a short time.

This PR is not backward compatible (due to pydantic breaking changes). I'm not sure if we should make this library compatible with both pydantic v1 & v2. Or maybe we should add another abstract layer so that we can make it possible to support pydantic v1 & v2 and msgspec (ref #307)

[yedpodtrzitko]

That's a huge contribution, your effort is really appreciated.

Pydantic v2 however still have some bugs and the ecosystem hasnt adapted yet, so I think it's too early to merge this at this moment.

[jaykv]

I understand of course, this is definitely just here to get the conversation started and test the waters.

So is the ideal separation of layers for future spectree this?

1. Request/response model validation (pydantic v1/v2, msgspec)
2. OpenAPI schema generation
3. Route parsing, generation and validation integration into backends (flask, falcon, starlette, quart)
4. Apidocs (swagger, redoc)

[kemingy]

I understand of course, this is definitely just here to get the conversation started and test the waters.

So is the ideal separation of layers for future spectree this?

1. Request/response model validation (pydantic v1/v2, msgspec)

2. OpenAPI schema generation

3. Route parsing, generation and validation integration into backends (flask, falcon, starlette, quart)

4. Apidocs (swagger, redoc)

Yeah. I wonder if we can detect the model (pydantic v1/v2, megspec) automatically. This layer should be used to validate the request/response and generate the OpenAPI model schema.

[AndreiDrang]

Hi
Perhaps it makes sense to just make a separate library? Smth like spectreeV2?

[kemingy]

Hi Perhaps it makes sense to just make a separate library? Smth like spectreeV2?

You can use pip install git+https://github.com/0b01001001/spectree.git@refs/pull/319/head directly.

[DanCardin]

At least for v2, pydantic appears to be including a v1 backport under pydantic.v1 inside the v2 versions. That may or may not be useful in terms of converting internal usage or making it cross-compatible.

But it seems like it might make it possible for the library at current moment to "simply" alias all of its imports to pydantic to the v1 version. Such that I, as a user of pydantic (that doesn't necessarily stop at API models) could upgrade to v2 without impacting the spectree-compatible v1 API models.

[kemingy]

At least for v2, pydantic appears to be including a v1 backport under pydantic.v1 inside the v2 versions. That may or may not be useful in terms of converting internal usage or making it cross-compatible.

But it seems like it might make it possible for the library at current moment to "simply" alias all of its imports to pydantic to the v1 version. Such that I, as a user of pydantic (that doesn't necessarily stop at API models) could upgrade to v2 without impacting the spectree-compatible v1 API models.

This sounds like a good temporary solution.

[jaykv]

At least for v2, pydantic appears to be including a v1 backport under pydantic.v1 inside the v2 versions. That may or may not be useful in terms of converting internal usage or making it cross-compatible.

But it seems like it might make it possible for the library at current moment to "simply" alias all of its imports to pydantic to the v1 version. Such that I, as a user of pydantic (that doesn't necessarily stop at API models) could upgrade to v2 without impacting the spectree-compatible v1 API models.

I've seen this approach used specifically with just:

try:
    from pydantic import v1 as pydantic
except ImportError:
    import pydantic

I didn't explore this yet, but could be worth looking into since it's a smaller change and also less likely to break for current v1 users. The only downside is spectree internally would still be using the v1 API instead of the v2 API. Although, that might not even matter since the long-term plan is to rehaul the internals to support msgspec anyways.

#324 is exploring the reverse approach for fun and upgrading the code to v2 API and creating backports for v1 and version-specific logic to handle the breaking changes.