Pydantic 2.0 Migration Plan

[vpwang]

Description The Pydantic version is limited to V1 in this package. However, the V2 version has added many useful features, such as customizable serializers. As both fhir.resources and FastAPI have supported Pydantic V2, will there be a plan for fhirstarter to upgrade to support the Pydantic V2?

What I Did pip install fhir.resources -U After starting the server, I got an error: ImportError: cannot import name 'display_errors' from 'pydantic.error_wrappers' (/usr/local/lib/python3.9/site-packages/pydantic/error_wrappers.py)

Related Package Versions pydantic 2.7.2 pydantic_core 2.18.3 fhir.resources 7.1.0 fhirstarter 2.4.0 fastapi 0.111.0 fastapi-cli 0.0.3

[csande]

Thank you for the request.

Off the top of my head, here is what I am aware of that would need to change:

• The display_errors function is imported in order to format the errors in the validation error exception during the creation of an OperationOutcome. Writing a replacement would likely be trivial.
• fhir.resources dropped support for FHIR R4. FHIRStarter supports sequence R4 by enabling the developer to install an older version of fhir.resources which I believe does not support pydantic >= 2.0. Given this, there are one of two paths to take:
  • Continue support for R4 and conditionally handle both pydantic < 2.0 and >= 2.0 in the pyproject dependencies, and in the code itself. Most of the code changes would likely be related to how custom examples for models are defined.
  • Drop support for R4. This would be much easier, but some still use R4, including me.

There might be a few more, but that is what I'm aware of at the moment.

To answer your specific question, yes, FHIRStarter will support Pydantic 2.0 in the future, though I don't have a specific timeline at the moment.

[csande]

One more note on this — I didn't know this, but apparently FHIR R4B is functionally equivalent to FHIR R4.

Given this, my feeling is that the best path forward for this would be to drop support for R4 to avoid having to conditionally support both.

[csande]

I spent a little time looking at this in more detail today. It actually turns out that fhir.resources does not yet support Pydantic v2. What the maintainers actually did was enable fhir.resources to depend on the latest version of the Pydantic package. That package actually includes both v1 and v2, with v1 being accessible via a distinct import path. All of the FHIR models derive from the v1 BaseModel. More details are here: https://github.com/nazrulworld/fhir.resources/issues/133

When fhir.resources does release a new version that supports Pydantic v2, I expect it to be straightforward to upgrade FHIRStarter, but it will also require dropping support for FHIR R4 as detailed in my previous comment. Supporting R4 would require support for both Pydantic v1 and v2; having continued R4 support would not be worth that added complexity.

Incidentally, I also did some research into the differences between FHIR R4 and FHIR R4B. FHIR R4 is mostly, but not entirely, a subset of R4B. So most users, with a few exceptions, would be able to use R4B without issue. More detail here: https://hl7.org/fhir/R4B/r4b-explanation.html

I will leave this open given that this will be addressed in the future.

[csande]

For future reference — I read through the Pydantic migration guide and took notes on what seemed relevant:

• dict() -> model_dump()
• json() -> model_dump_json()
• workaround for indent and ensure_ascii: https://github.com/pydantic/pydantic/issues/8825#issuecomment-1946206415
• Config class -> model_config attribute
• schema_extra -> json_schema_extra
• pydantic.error_wrappers.ValidationError moved to pydantic.ValidationError

Additional work needed:

• Find all references to Pydantic and update as necessary
• Verify Swagger/OpenAPI
• Disable R4
• Update README