From b06aa125466914b9e0814411881833cd85e49784 Mon Sep 17 00:00:00 2001 From: GitHub Date: Sun, 31 Dec 2023 23:29:22 +0000 Subject: [PATCH] chore: prepare release 0.17.0 --- ...s_use_correct_content_type_for_requests.md | 9 --- .changeset/openapi_31_support.md | 22 ------ ...parameter_nullablerequired_special_case.md | 7 -- .../renamed_body_types_and_parameters.md | 29 ------- .../support_multiple_possible_requestbody.md | 16 ---- CHANGELOG.md | 76 +++++++++++++++++++ pyproject.toml | 2 +- 7 files changed, 77 insertions(+), 84 deletions(-) delete mode 100644 .changeset/always_use_correct_content_type_for_requests.md delete mode 100644 .changeset/openapi_31_support.md delete mode 100644 .changeset/removed_query_parameter_nullablerequired_special_case.md delete mode 100644 .changeset/renamed_body_types_and_parameters.md delete mode 100644 .changeset/support_multiple_possible_requestbody.md diff --git a/.changeset/always_use_correct_content_type_for_requests.md b/.changeset/always_use_correct_content_type_for_requests.md deleted file mode 100644 index bb4ff4f0b..000000000 --- a/.changeset/always_use_correct_content_type_for_requests.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -default: patch ---- - -# Always use correct content type for requests - -In previous versions, a request body that was similar to a known content type would use that content type in the request. For example `application/json` would be used for `application/vnd.api+json`. This was incorrect and could result in invalid requests being sent. - -Now, the content type defined in the OpenAPI document will always be used. diff --git a/.changeset/openapi_31_support.md b/.changeset/openapi_31_support.md deleted file mode 100644 index cf890d64b..000000000 --- a/.changeset/openapi_31_support.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -default: minor ---- - -# OpenAPI 3.1 support - -The generator will now attempt to generate code for OpenAPI documents with versions 3.1.x (previously, it would exit immediately on seeing a version other than 3.0.x). The following specific OpenAPI 3.1 features are now supported: - -- `null` as a type -- Arrays of types (e.g., `type: [string, null]`) -- `const` (defines `Literal` types) - -The generator does not currently validate that the OpenAPI document is valid for a specific version of OpenAPI, so it may be possible to generate code for documents that include both removed 3.0 syntax (e.g., `nullable`) and new 3.1 syntax (e.g., `null` as a type). - -Thanks to everyone who helped make this possible with discussions and testing, including: - -- @frco9 -- @vogre -- @naddeoa -- @staticdev -- @philsturgeon -- @johnthagen diff --git a/.changeset/removed_query_parameter_nullablerequired_special_case.md b/.changeset/removed_query_parameter_nullablerequired_special_case.md deleted file mode 100644 index 77aad0a94..000000000 --- a/.changeset/removed_query_parameter_nullablerequired_special_case.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -default: major ---- - -# Removed query parameter nullable/required special case - -In previous versions, setting _either_ `nullable: true` or `required: false` on a query parameter would act like both were set, resulting in a type signature like `Union[None, Unset, YourType]`. This special case has been removed, query parameters will now act like all other types of parameters. diff --git a/.changeset/renamed_body_types_and_parameters.md b/.changeset/renamed_body_types_and_parameters.md deleted file mode 100644 index 7ab407cb7..000000000 --- a/.changeset/renamed_body_types_and_parameters.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -default: major ---- - -# Renamed body types and parameters - -PR #900 addresses #822. - -Where previously there would be one body parameter per supported content type, now there is a single `body` parameter which takes a union of all the possible inputs. This correctly models the fact that only one body can be sent (and ever would be sent) in a request. - -For example, when calling a generated endpoint, code which used to look like this: - -```python -post_body_multipart.sync_detailed( - client=client, - multipart_data=PostBodyMultipartMultipartData(), -) -``` - -Will now look like this: - -```python -post_body_multipart.sync_detailed( - client=client, - body=PostBodyMultipartBody(), -) -``` - -Note that both the input parameter name _and_ the class name have changed. This should result in simpler code when there is only a single body type and now produces correct code when there are multiple body types. diff --git a/.changeset/support_multiple_possible_requestbody.md b/.changeset/support_multiple_possible_requestbody.md deleted file mode 100644 index 446374d16..000000000 --- a/.changeset/support_multiple_possible_requestbody.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -default: minor ---- - -# Support multiple possible `requestBody` - -PR #900 addresses #822. - -It is now possible in some circumstances to generate valid code for OpenAPI documents which have multiple possible `requestBody` values. Previously, invalid code could have been generated with no warning (only one body could actually be sent). - -Only one content type per "category" is currently supported at a time. The categories are: - -- JSON, like `application/json` -- Binary data, like `application/octet-stream` -- Encoded form data, like `application/x-www-form-urlencoded` -- Files, like `multipart/form-data` diff --git a/CHANGELOG.md b/CHANGELOG.md index b2b13c5b7..ad6a0de51 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -13,6 +13,82 @@ Programmatic usage of this project (e.g., importing it as a Python module) and t The 0.x prefix used in versions for this project is to indicate that breaking changes are expected frequently (several times a year). Breaking changes will increment the minor number, all other changes will increment the patch number. You can track the progress toward 1.0 [here](https://github.com/openapi-generators/openapi-python-client/projects/2). +## 0.17.0 (2023-12-31) + +### Breaking Changes + +#### Removed query parameter nullable/required special case + +In previous versions, setting _either_ `nullable: true` or `required: false` on a query parameter would act like both were set, resulting in a type signature like `Union[None, Unset, YourType]`. This special case has been removed, query parameters will now act like all other types of parameters. + +#### Renamed body types and parameters + +PR #900 addresses #822. + +Where previously there would be one body parameter per supported content type, now there is a single `body` parameter which takes a union of all the possible inputs. This correctly models the fact that only one body can be sent (and ever would be sent) in a request. + +For example, when calling a generated endpoint, code which used to look like this: + +```python +post_body_multipart.sync_detailed( + client=client, + multipart_data=PostBodyMultipartMultipartData(), +) +``` + +Will now look like this: + +```python +post_body_multipart.sync_detailed( + client=client, + body=PostBodyMultipartBody(), +) +``` + +Note that both the input parameter name _and_ the class name have changed. This should result in simpler code when there is only a single body type and now produces correct code when there are multiple body types. + +### Features + +#### OpenAPI 3.1 support + +The generator will now attempt to generate code for OpenAPI documents with versions 3.1.x (previously, it would exit immediately on seeing a version other than 3.0.x). The following specific OpenAPI 3.1 features are now supported: + +- `null` as a type +- Arrays of types (e.g., `type: [string, null]`) +- `const` (defines `Literal` types) + +The generator does not currently validate that the OpenAPI document is valid for a specific version of OpenAPI, so it may be possible to generate code for documents that include both removed 3.0 syntax (e.g., `nullable`) and new 3.1 syntax (e.g., `null` as a type). + +Thanks to everyone who helped make this possible with discussions and testing, including: + +- @frco9 +- @vogre +- @naddeoa +- @staticdev +- @philsturgeon +- @johnthagen + +#### Support multiple possible `requestBody` + +PR #900 addresses #822. + +It is now possible in some circumstances to generate valid code for OpenAPI documents which have multiple possible `requestBody` values. Previously, invalid code could have been generated with no warning (only one body could actually be sent). + +Only one content type per "category" is currently supported at a time. The categories are: + +- JSON, like `application/json` +- Binary data, like `application/octet-stream` +- Encoded form data, like `application/x-www-form-urlencoded` +- Files, like `multipart/form-data` + +### Fixes + +#### Always use correct content type for requests + +In previous versions, a request body that was similar to a known content type would use that content type in the request. For example `application/json` would be used for `application/vnd.api+json`. This was incorrect and could result in invalid requests being sent. + +Now, the content type defined in the OpenAPI document will always be used. + ## 0.16.1 (2023-12-23) ### Features diff --git a/pyproject.toml b/pyproject.toml index 65d850ddd..7a783873b 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [tool.poetry] name = "openapi-python-client" -version = "0.16.1" +version = "0.17.0" description = "Generate modern Python clients from OpenAPI" repository = "https://github.com/triaxtec/openapi-python-client" license = "MIT"