[PoC] Add support for pydantic models via datamodel-code-generator

[felixatmaltego]

Hi!

I really like this library and use it for all my clients. Unfortunately, I use pydantic in my FastAPI projects. Converting attrs to pydantic models is possible, but a bit cumbersome. Instead, I found an easy way to use pydantic models with openapi-python-client.

While openapi-python-client generates attrs models with custom parser logic, it is nicer for me to use pydantic as in the
rest of my FastAPI projects. Therefore, we generate the models with datamodel-code-generator, and the client logic
with openapi-python-client.

To make this possible, only two important changes are necessary:

• use BaseModel::model_validate(...) instead of the custom from_dict(...) method generated
  by openapi-python-client
• change the imports from from ...models.<model-dir> import <Model> to from ...models import <Model>,
  because datamodel-code-generator creates a flat file

templates/property_templates/model_property.py.jinja

--- model_property.py.original.jinja	2024-06-06 17:54:48
+++ model_property.py.jinja	2024-06-06 19:07:31
@@ -1,5 +1,5 @@
 {% macro construct_function(property, source) %}
-{{ property.class_info.name }}.from_dict({{ source }})
+{{ property.class_info.name }}.model_validate({{ source }})
 {% endmacro %}
 
 {% from "property_templates/property_macros.py.jinja" import construct_template %}

templates/endpoint_module.py.jinja

--- endpoint_module.py.original.jinja	2024-06-06 17:45:47
+++ endpoint_module.py.jinja	2024-06-06 18:25:13
@@ -3,12 +3,22 @@
 
 import httpx
 
+{% macro transform_import(original_string) -%}
+    {%- if original_string.startswith('from ...models') -%}
+        {%- set parts = original_string.split(' ') -%}
+        {%- set new_string = 'from ...models import ' + parts[3] -%}
+        {{ new_string }}
+    {%- else -%}
+        {{ original_string }}
+    {%- endif -%}
+{%- endmacro %}
+
 from ...client import AuthenticatedClient, Client
 from ...types import Response, UNSET
 from ... import errors
 
 {% for relative in endpoint.relative_imports %}
-{{ relative }}
+{{ transform_import(relative) }}
 {% endfor %}
 
 {% from "endpoint_macros.py.jinja" import header_params, cookie_params, query_params,

To generate our modified client, we have to:

• generate the client as normal
• delete all files in openapi-client/openapi_client/models/*
• generate our pydantic models to openapi-client/openapi_client/models/__init__.py

I created a small shell script to do this

# openapi-python-client generate --path openapi.json --custom-template-path=templates
openapi-python-client update --path openapi.json --custom-template-path=templates

rm -r openapi-client/openapi_client/models/*

datamodel-codegen --input openapi.json \
  --output-model-type pydantic_v2.BaseModel \
  --strict-nullable --snake-case-field --capitalize-enum-members \
  --use-union-operator --use-standard-collections \
  > openapi-client/openapi_client/models/__init__.py

The --strict-nullable --snake-case-field --capitalize-enum-members flags were necessary to be equivalent to the attrs models.

Another thing is that openapi-python-client suffixes reserved names with an '_'. I had to change those occurences.
Apart from that, the resulting code is compatible with the attrs models.

Hope this helps someone. Would be amazing to see this as a feature!

[JoeGaffney]

Yes wondering why the pydantic models are not used by default maybe there's some reason to make it more general purpose. Ran into this when using some endpoints that are pass through and was hoping to reuse the model that was generated.

But like you mentioned an option to choose to generate the pydantic models would be great.

[markns]

This was a very helpful post, thanks @felixatmaltego!

I found I had to monkey patch the pydantic BaseModel to get the generated client to work:

def dump_dict(self):
    return self.model_dump()

# Apply the monkey-patch
BaseModel.to_dict = dump_dict

Otherwise it fails at the line:

def _get_kwargs)
...
   
    _body = body.to_dict() # fails here