dependabot[bot] opened a new pull request, #18638: URL: https://github.com/apache/iceberg/pull/18638
Bumps [datamodel-code-generator](https://github.com/datamodel-code-generator/datamodel-code-generator) from 0.82.0 to 0.85.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/datamodel-code-generator/datamodel-code-generator/releases";>datamodel-code-generator's releases</a>.</em></p> <blockquote> <h2>0.85.0</h2> <h2>Breaking Changes</h2> <h3>Error Handling Changes</h3> <ul> <li>Output encoding failures now raise <code>Error</code> instead of raw codec exceptions - Generated output, model metadata from <code>--emit-model-metadata</code>, and API target package files are now encoded before anything is written. If the chosen <code>--encoding</code> / <code>encoding</code> cannot encode the text, <code>generate()</code> raises <code>datamodel_code_generator.Error</code> with the message <code>Unable to encode output using encoding '...': ...</code> instead of letting <code>UnicodeEncodeError</code> escape. The CLI now prints this as a single error line and exits with code 2 instead of showing a traceback. Python API callers that caught <code>UnicodeEncodeError</code> or <code>UnicodeError</code> need to catch <code>Error</code> instead. Also, when one module of a modular output fails to encode, no files are written; before, earlier modules could be written before the failure (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-ge nerator/issues/4615">#4615</a>)</li> <li>Unknown or non-text encodings are rejected up front with <code>Error</code> - <code>generate()</code> now checks the <code>encoding</code> option during config preparation, before any input is read or any output path is created. An unknown encoding such as <code>nosuch</code>, or a codec that is not a text encoding such as <code>hex</code>, now raises <code>datamodel_code_generator.Error</code> (CLI exit code 2, one-line message) instead of a raw <code>LookupError</code> raised later. Code that caught <code>LookupError</code> for a bad encoding must catch <code>Error</code> instead (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4615";>#4615</a>)</li> <li>Explicit names are now checked as identifiers of the target Python version - This applies to <code>--class-name</code>, <code>--class-name-prefix</code>, <code>--class-name-suffix</code>, <code>--special-field-name-prefix</code>, <code>--model-name-map</code> values and explicit field aliases. It also applies to client and FastAPI generation settings such as <code>package</code>, <code>model_package</code>, resource namespaces, operation, parameter and router names, and protocol helper names. These are now checked against the identifier rules of <code>--target-python-version</code>, not the running interpreter, so a name that uses characters only a newer Python accepts is now rejected (for example with <code>E_CONFIG_VALUE</code> or an invalid identifier error) when targeting an older Python, even if the running interpreter accepts it (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4790";>#4790</a>)</li> <li>Generation now fails when an override or schema import names a standard-library type the target lacks - A standard-library type named by <code>--type-overrides</code>, <code>customTypePath</code> or <code>x-python-import</code> (including its <code>qualname</code> and <code>native-field</code> paths) that does not exist in the target Python version now stops generation with <code>TYPE is unavailable for target Python X.Y</code>. Examples are <code>enum.StrEnum</code> for 3.10, <code>pathlib.types.PathInfo</code> for 3.13, <code>builtins.frozendict</code> for 3.14 and <code>pathlib.DirEntryInfo</code> for 3.15. Before this change the import was written as given and generation succeeded. The check runs only when the final output imports the type. To fix this, raise <code>--target-python-version</code> or use <code>--import-overrides</code> to point the import at a backport module, for example <code>--import-overrides '{"StrEnum": "backports.strenum"}'</code>. (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4788";>#4788</a>)</li> </ul> <h3>Code Generation Changes</h3> <ul> <li>Non-ASCII identifiers now follow the target Python version's Unicode rules - Field names, class names, enum member names, module names, alias generator output (<code>to_camel</code>, <code>to_pascal</code>, <code>to_snake</code>), OpenAPI operation model names and the builtin formatter's import ordering are now worked out from Unicode tables for <code>--target-python-version</code>. Those tables cover identifier characters, <code>\w</code>, numeric characters, case mappings and NFKC normalization. Before, these names came from the <code>str</code>, <code>re</code> and <code>unicodedata</code> behaviour of the interpreter running datamodel-codegen. ASCII names are unaffected, but output for non-ASCII schema names can change when the running interpreter's Unicode version differs from the target's. For example, a property <code>京都</code> (U+4EAC is numeric from Python 3.13) used to become <code>field_京都</code> when generated on Python 3.13 or later. It is now emitted as < code>京都</code> for targets up to 3.12, and the reverse happens when generating on an older Python for a 3.13 or later target. Likewise, <code>--capitalise-enum-members</code> no longer turns <code>ɤ</code> into <code></code> for targets older than 3.14, even when running on Python 3.14. Regenerate and review models whose names contain non-ASCII characters, because renamed fields and members break code that refers to them (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4790";>#4790</a>)</li> <li>Newer typing names from type overrides and schema import paths now come from <code>typing_extensions</code> - Standard-library <code>typing</code> or <code>collections.abc</code> names given through <code>--type-overrides</code>, <code>customTypePath</code> or <code>x-python-import</code> are now resolved against <code>--target-python-version</code>. If the name is newer than the target, the import now comes from <code>typing_extensions</code>. For example, <code>typing.LiteralString</code> and <code>collections.abc.Buffer</code> with target 3.10 now produce <code>from typing_extensions import Buffer, LiteralString</code> instead of importing them from <code>typing</code> and <code>collections.abc</code> as before. Projects that compare generated output, or that do not have <code>typing_extensions</code> installed, will see different imports. (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4788";>#4788</a>)</li> <li>Builtin formatter groups standard library imports by target Python version - With <code>--formatters builtin</code>, whether an import goes in the standard library section or the third party section now depends on the standard library modules of <code>--target-python-version</code>. When no target is given, the minimum supported target, 3.10, is used. Before this change, the formatter used <code>sys.stdlib_module_names</code> of the running interpreter. When the running Python differs from the target, imports in generated files can move to a different section. For example, <code>tomllib</code> is grouped as third party when targeting 3.10, <code>distutils</code> is grouped as standard library when targeting 3.10 even on a newer interpreter, and <code>sre_parse</code> becomes third party while <code>profiling</code> becomes standard library when targeting 3.15 (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4791";>#4791</a>)</li> <li>Builtin formatter places each module of a multi-module import in its own section - With <code>--formatters builtin</code>, an <code>import a, b, c</code> statement that names modules from different categories (standard library, third party, first party) now puts each module in its own section, as isort does. Before, all modules from that statement went into the section of the highest-priority module among them, so the order of generated imports can change (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4791";>#4791</a>)</li> <li>Reuse model now deduplicates models whose referenced names start with non-ASCII letters - With <code>--reuse-model</code>, model names that start with characters beyond ASCII (for example <code>Ñumber</code> or <code>Ölen</code>) are now masked as whole identifiers when models are compared. Models that are identical except for such references are now reused as subclasses (for example <code>class Distance(Speed): pass</code>) instead of being generated as separate duplicate classes. This matches how ASCII names already worked. As a result, some previously generated duplicate classes and their numbered names may no longer appear in the output (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4791";>#4791</a>)</li> </ul> <!-- raw HTML omitted --> <h2>What's Changed</h2> <ul> <li>fix: report output encoding failures without truncating the file by <a href="https://github.com/mvanhorn";><code>@mvanhorn</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4615";>datamodel-code-generator/datamodel-code-generator#4615</a></li> <li>Add Python 3.15 as a target version by <a href="https://github.com/Kaboka22";><code>@Kaboka22</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4609";>datamodel-code-generator/datamodel-code-generator#4609</a></li> <li>Lock dependencies with Python 3.15 wheels by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4766";>datamodel-code-generator/datamodel-code-generator#4766</a></li> <li>Run the test suite on Python 3.15 in CI by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4768";>datamodel-code-generator/datamodel-code-generator#4768</a></li> <li>Keep target names and type imports independent of the host for Python 3.15 by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4769";>datamodel-code-generator/datamodel-code-generator#4769</a></li> <li>Use the newest target when the interpreter is newer than every target by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4770";>datamodel-code-generator/datamodel-code-generator#4770</a></li> <li>Name the black requirement when black cannot format the target by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4771";>datamodel-code-generator/datamodel-code-generator#4771</a></li> <li>Add 20261015 presets with Python 3.15 targets by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4772";>datamodel-code-generator/datamodel-code-generator#4772</a></li> <li>Document Python 3.15 targets by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4773";>datamodel-code-generator/datamodel-code-generator#4773</a></li> <li>Read builtin names for field collisions from the static target table by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4786";>datamodel-code-generator/datamodel-code-generator#4786</a></li> <li>Follow the target Python's Unicode version for generated names by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4790";>datamodel-code-generator/datamodel-code-generator#4790</a></li> <li>Group the builtin formatter's imports by the target Python's standard library by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4791";>datamodel-code-generator/datamodel-code-generator#4791</a></li> <li>Take the target Python of model type decisions from the field configuration by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4787";>datamodel-code-generator/datamodel-code-generator#4787</a></li> <li>Check type overrides, customTypePath and x-python-import against the target Python by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4788";>datamodel-code-generator/datamodel-code-generator#4788</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/Kaboka22";><code>@Kaboka22</code></a> made their first contribution in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4609";>datamodel-code-generator/datamodel-code-generator#4609</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/datamodel-code-generator/datamodel-code-generator/compare/0.84.0...0.85.0";>https://github.com/datamodel-code-generator/datamodel-code-generator/compare/0.84.0...0.85.0</a></p> <h2>0.84.0</h2> <h2>Highlights</h2> <h3>Experimental: FastAPI server and Python client generation</h3> <p>Besides the models, datamodel-code-generator can now generate a FastAPI server package and a typed HTTPX2 client from one OpenAPI document. Both are <strong>new in 0.84.0 and experimental</strong>: options, templates and the generated packages may change in later releases (they are listed in the experimental registry with <code>since_version</code> 0.84.0). The generated code uses your generated models as its runtime contract: they validate requests and responses, and the generated server reads its packaged copy of the OpenAPI document only to serve it.</p> <p>Get started:</p> <pre lang="bash"><code># FastAPI server package in app/server/ (mkdir app && touch app/__init__.py first) </tr></table> </code></pre> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/datamodel-code-generator/datamodel-code-generator/blob/main/CHANGELOG.md";>datamodel-code-generator's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/releases/tag/0.85.0";>0.85.0</a> - 2026-10-16</h2> <h2>Breaking Changes</h2> <h3>Error Handling Changes</h3> <ul> <li>Output encoding failures now raise <code>Error</code> instead of raw codec exceptions - Generated output, model metadata from <code>--emit-model-metadata</code>, and API target package files are now encoded before anything is written. If the chosen <code>--encoding</code> / <code>encoding</code> cannot encode the text, <code>generate()</code> raises <code>datamodel_code_generator.Error</code> with the message <code>Unable to encode output using encoding '...': ...</code> instead of letting <code>UnicodeEncodeError</code> escape. The CLI now prints this as a single error line and exits with code 2 instead of showing a traceback. Python API callers that caught <code>UnicodeEncodeError</code> or <code>UnicodeError</code> need to catch <code>Error</code> instead. Also, when one module of a modular output fails to encode, no files are written; before, earlier modules could be written before the failure (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-ge nerator/issues/4615">#4615</a>)</li> <li>Unknown or non-text encodings are rejected up front with <code>Error</code> - <code>generate()</code> now checks the <code>encoding</code> option during config preparation, before any input is read or any output path is created. An unknown encoding such as <code>nosuch</code>, or a codec that is not a text encoding such as <code>hex</code>, now raises <code>datamodel_code_generator.Error</code> (CLI exit code 2, one-line message) instead of a raw <code>LookupError</code> raised later. Code that caught <code>LookupError</code> for a bad encoding must catch <code>Error</code> instead (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4615";>#4615</a>)</li> <li>Explicit names are now checked as identifiers of the target Python version - This applies to <code>--class-name</code>, <code>--class-name-prefix</code>, <code>--class-name-suffix</code>, <code>--special-field-name-prefix</code>, <code>--model-name-map</code> values and explicit field aliases. It also applies to client and FastAPI generation settings such as <code>package</code>, <code>model_package</code>, resource namespaces, operation, parameter and router names, and protocol helper names. These are now checked against the identifier rules of <code>--target-python-version</code>, not the running interpreter, so a name that uses characters only a newer Python accepts is now rejected (for example with <code>E_CONFIG_VALUE</code> or an invalid identifier error) when targeting an older Python, even if the running interpreter accepts it (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4790";>#4790</a>)</li> <li>Generation now fails when an override or schema import names a standard-library type the target lacks - A standard-library type named by <code>--type-overrides</code>, <code>customTypePath</code> or <code>x-python-import</code> (including its <code>qualname</code> and <code>native-field</code> paths) that does not exist in the target Python version now stops generation with <code>TYPE is unavailable for target Python X.Y</code>. Examples are <code>enum.StrEnum</code> for 3.10, <code>pathlib.types.PathInfo</code> for 3.13, <code>builtins.frozendict</code> for 3.14 and <code>pathlib.DirEntryInfo</code> for 3.15. Before this change the import was written as given and generation succeeded. The check runs only when the final output imports the type. To fix this, raise <code>--target-python-version</code> or use <code>--import-overrides</code> to point the import at a backport module, for example <code>--import-overrides '{"StrEnum": "backports.strenum"}'</code>. (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4788";>#4788</a>)</li> </ul> <h3>Code Generation Changes</h3> <ul> <li>Non-ASCII identifiers now follow the target Python version's Unicode rules - Field names, class names, enum member names, module names, alias generator output (<code>to_camel</code>, <code>to_pascal</code>, <code>to_snake</code>), OpenAPI operation model names and the builtin formatter's import ordering are now worked out from Unicode tables for <code>--target-python-version</code>. Those tables cover identifier characters, <code>\w</code>, numeric characters, case mappings and NFKC normalization. Before, these names came from the <code>str</code>, <code>re</code> and <code>unicodedata</code> behaviour of the interpreter running datamodel-codegen. ASCII names are unaffected, but output for non-ASCII schema names can change when the running interpreter's Unicode version differs from the target's. For example, a property <code>京都</code> (U+4EAC is numeric from Python 3.13) used to become <code>field_京都</code> when generated on Python 3.13 or later. It is now emitted as < code>京都</code> for targets up to 3.12, and the reverse happens when generating on an older Python for a 3.13 or later target. Likewise, <code>--capitalise-enum-members</code> no longer turns <code>ɤ</code> into <code></code> for targets older than 3.14, even when running on Python 3.14. Regenerate and review models whose names contain non-ASCII characters, because renamed fields and members break code that refers to them (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4790";>#4790</a>)</li> <li>Newer typing names from type overrides and schema import paths now come from <code>typing_extensions</code> - Standard-library <code>typing</code> or <code>collections.abc</code> names given through <code>--type-overrides</code>, <code>customTypePath</code> or <code>x-python-import</code> are now resolved against <code>--target-python-version</code>. If the name is newer than the target, the import now comes from <code>typing_extensions</code>. For example, <code>typing.LiteralString</code> and <code>collections.abc.Buffer</code> with target 3.10 now produce <code>from typing_extensions import Buffer, LiteralString</code> instead of importing them from <code>typing</code> and <code>collections.abc</code> as before. Projects that compare generated output, or that do not have <code>typing_extensions</code> installed, will see different imports. (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4788";>#4788</a>)</li> <li>Builtin formatter groups standard library imports by target Python version - With <code>--formatters builtin</code>, whether an import goes in the standard library section or the third party section now depends on the standard library modules of <code>--target-python-version</code>. When no target is given, the minimum supported target, 3.10, is used. Before this change, the formatter used <code>sys.stdlib_module_names</code> of the running interpreter. When the running Python differs from the target, imports in generated files can move to a different section. For example, <code>tomllib</code> is grouped as third party when targeting 3.10, <code>distutils</code> is grouped as standard library when targeting 3.10 even on a newer interpreter, and <code>sre_parse</code> becomes third party while <code>profiling</code> becomes standard library when targeting 3.15 (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4791";>#4791</a>)</li> <li>Builtin formatter places each module of a multi-module import in its own section - With <code>--formatters builtin</code>, an <code>import a, b, c</code> statement that names modules from different categories (standard library, third party, first party) now puts each module in its own section, as isort does. Before, all modules from that statement went into the section of the highest-priority module among them, so the order of generated imports can change (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4791";>#4791</a>)</li> <li>Reuse model now deduplicates models whose referenced names start with non-ASCII letters - With <code>--reuse-model</code>, model names that start with characters beyond ASCII (for example <code>Ñumber</code> or <code>Ölen</code>) are now masked as whole identifiers when models are compared. Models that are identical except for such references are now reused as subclasses (for example <code>class Distance(Speed): pass</code>) instead of being generated as separate duplicate classes. This matches how ASCII names already worked. As a result, some previously generated duplicate classes and their numbered names may no longer appear in the output (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4791";>#4791</a>)</li> </ul> <!-- raw HTML omitted --> <h2>What's Changed</h2> <ul> <li>fix: report output encoding failures without truncating the file by <a href="https://github.com/mvanhorn";><code>@mvanhorn</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4615";>datamodel-code-generator/datamodel-code-generator#4615</a></li> <li>Add Python 3.15 as a target version by <a href="https://github.com/Kaboka22";><code>@Kaboka22</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4609";>datamodel-code-generator/datamodel-code-generator#4609</a></li> <li>Lock dependencies with Python 3.15 wheels by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4766";>datamodel-code-generator/datamodel-code-generator#4766</a></li> <li>Run the test suite on Python 3.15 in CI by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4768";>datamodel-code-generator/datamodel-code-generator#4768</a></li> <li>Keep target names and type imports independent of the host for Python 3.15 by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4769";>datamodel-code-generator/datamodel-code-generator#4769</a></li> <li>Use the newest target when the interpreter is newer than every target by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4770";>datamodel-code-generator/datamodel-code-generator#4770</a></li> <li>Name the black requirement when black cannot format the target by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4771";>datamodel-code-generator/datamodel-code-generator#4771</a></li> <li>Add 20261015 presets with Python 3.15 targets by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4772";>datamodel-code-generator/datamodel-code-generator#4772</a></li> <li>Document Python 3.15 targets by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4773";>datamodel-code-generator/datamodel-code-generator#4773</a></li> <li>Read builtin names for field collisions from the static target table by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4786";>datamodel-code-generator/datamodel-code-generator#4786</a></li> <li>Follow the target Python's Unicode version for generated names by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4790";>datamodel-code-generator/datamodel-code-generator#4790</a></li> <li>Group the builtin formatter's imports by the target Python's standard library by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4791";>datamodel-code-generator/datamodel-code-generator#4791</a></li> <li>Take the target Python of model type decisions from the field configuration by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4787";>datamodel-code-generator/datamodel-code-generator#4787</a></li> <li>Check type overrides, customTypePath and x-python-import against the target Python by <a href="https://github.com/koxudaxi";><code>@koxudaxi</code></a> in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4788";>datamodel-code-generator/datamodel-code-generator#4788</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/Kaboka22";><code>@Kaboka22</code></a> made their first contribution in <a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/pull/4609";>datamodel-code-generator/datamodel-code-generator#4609</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/datamodel-code-generator/datamodel-code-generator/compare/0.84.0...0.85.0";>https://github.com/datamodel-code-generator/datamodel-code-generator/compare/0.84.0...0.85.0</a></p> <hr /> <h2><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/releases/tag/0.84.0";>0.84.0</a> - 2026-10-15</h2> <h2>Highlights</h2> <h3>Experimental: FastAPI server and Python client generation</h3> <p>Besides the models, datamodel-code-generator can now generate a FastAPI server package and a typed HTTPX2 client from one OpenAPI document. Both are <strong>new in 0.84.0 and experimental</strong>: options, templates and the generated packages may change in later releases (they are listed in the experimental registry with <code>since_version</code> 0.84.0). The generated code uses your generated models as its runtime contract: they validate requests and responses, and the generated server reads its packaged copy of the OpenAPI document only to serve it.</p> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/723f9e38523e074182674adeac3a8c6fcdf3d955";><code>723f9e3</code></a> Check type overrides, customTypePath and x-python-import against the target P...</li> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/c20e85b2cebe7d2969bfad064440873a66920224";><code>c20e85b</code></a> Take the target Python of model type decisions from the field configuration (...</li> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/7fa825d202b42933a6f58f7a4bf4e46ade19cc52";><code>7fa825d</code></a> Group the builtin formatter's imports by the target Python's standard library...</li> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/bfc6e0a4380f984f7af4c86b1f3dfd9d26ea7ff6";><code>bfc6e0a</code></a> Follow the target Python's Unicode version for generated names (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4790";>#4790</a>)</li> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/90a8690e3b81ec738e9e6639e2a691d00e39207b";><code>90a8690</code></a> Read builtin names for field collisions from the static target table (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4786";>#4786</a>)</li> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/8733b045c3f4d6faa468e0f0e332c07a0d96f553";><code>8733b04</code></a> Check property-name regexes and nested $schema in the payload regex filter (#...</li> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/000d4117dd67d0499a77ef38c6382ace7ef3b8c4";><code>000d411</code></a> Run the FastAPI server e2e on Python 3.15 in CI (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4780";>#4780</a>)</li> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/fa5c4814b6e2cb9b6320dc558ad995a5cffa1702";><code>fa5c481</code></a> Document Python 3.15 targets (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4773";>#4773</a>)</li> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/26b6d0b34b9c7c680a3712d74a42b66ab5938a07";><code>26b6d0b</code></a> Add 20261015 presets with Python 3.15 targets (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4772";>#4772</a>)</li> <li><a href="https://github.com/datamodel-code-generator/datamodel-code-generator/commit/494a10b8a335eb96ca80e2833942d45e1f0d5e64";><code>494a10b</code></a> Name the black requirement when black cannot format the target (<a href="https://redirect.github.com/datamodel-code-generator/datamodel-code-generator/issues/4771";>#4771</a>)</li> <li>Additional commits viewable in <a href="https://github.com/datamodel-code-generator/datamodel-code-generator/compare/0.82.0...0.85.0";>compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
