Tags: codebutler/openapi-python-client
Tags
chore: prepare release 0.17.2 (openapi-generators#932) This PR was created by Knope. Merging it will create a new release ### Features #### Add `--meta=pdm` option for generating PEP621 + PDM metadata The default metadata is still `--meta=poetry`, which generates a `pyproject.toml` file with Poetry-specific metadata. This change adds the `--meta=pdm` option which includes [PDM](https://pdm-project.org/latest/)-specific metadata, but also standard [PEP621](https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#writing-pyproject-toml) metadata. This may be useful as a starting point for other dependency managers & build tools (like Hatch). #### Add original OpenAPI `data` attribute to `Response` object PR openapi-generators#767 In custom templates, you can now access a `response.data` attribute that contains the original OpenAPI definition of the response (Response Object or Reference Object). #### Include the `UP` rule for generated Ruff config This enables [pyupgrade-like improvements](https://docs.astral.sh/ruff/rules/#pyupgrade-up) which should replace some `.format()` calls with f-strings. ### Fixes #### Fix Ruff formatting for `--meta=none` PR openapi-generators#940 fixes issue openapi-generators#939. Thanks @satwell! Due to the lack of `pyproject.toml`, Ruff was not getting configured properly when `--meta=none`. As a result, it didn't clean up common generation issues like duplicate imports, which would then cause errors from linters. This is now fixed by changing the default `post_hook` to `ruff check . --fix --extend-select=I` when `--meta=none`. Using `generate --meta=none` should now be almost identical to the code generated by `update`. Co-authored-by: GitHub <github-actions@github.com>
chore: prepare release 0.17.1 (openapi-generators#930) This PR was created by Knope. Merging it will create a new release ### Features #### Export `Unset` types from generated `types.py` (openapi-generators#927) #### Generate properties for some boolean enums If a schema has both `type = "boolean"` and `enum` defined, a normal boolean property will now be created. Previously, the generator would error. Note that the generate code _will not_ correctly limit the values to the enum values. To work around this, use the OpenAPI 3.1 `const` instead of `enum` to generate Python `Literal` types. Thanks for reporting openapi-generators#922 @macmoritz! ### Fixes #### Do not stop generation for invalid enum values This generator only supports `enum` values that are strings or integers. Previously, this was handled at the parsing level, which would cause the generator to fail if there were any unsupported values in the document. Now, the generator will correctly keep going, skipping only endpoints which contained unsupported values. Thanks for reporting openapi-generators#922 @macmoritz! #### Fix lists within unions Fixes openapi-generators#756 and openapi-generators#928. Arrays within unions (which, as of 0.17 includes nullable arrays) would generate invalid code. Thanks @kgutwin and @diesieben07! #### Simplify type checks for non-required unions Co-authored-by: GitHub <github-actions@github.com>
chore: prepare release 0.17.0 (openapi-generators#918) This PR was created by Knope. Merging it will create a new release ### 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 openapi-generators#900 addresses openapi-generators#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 openapi-generators#900 addresses openapi-generators#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. Co-authored-by: GitHub <github-actions@github.com>
chore: prepare release 0.16.1 (openapi-generators#915) This PR was created by Knope. Merging it will create a new release ### Features #### Support httpx 0.26 (openapi-generators#913) Co-authored-by: GitHub <github-actions@github.com>
chore: prepare release 0.16.0 (openapi-generators#871) This PR was created by Knope. Merging it will create a new release ### Breaking Changes #### Switch from Black to Ruff for formatting `black` is no longer a runtime dependency, so if you have them set in custom `post_hooks` in a config file, you'll need to make sure they're being installed manually. [`ruff`](https://docs.astral.sh/ruff) is now installed and used by default instead. #### Use Ruff instead of isort + autoflake at runtime `isort` and `autoflake` are no longer runtime dependencies, so if you have them set in custom `post_hooks` in a config file, you'll need to make sure they're being installed manually. [`ruff`](https://docs.astral.sh/ruff) is now installed and used by default instead. ### Features #### Support all `text/*` content types in responses Within an API response, any content type which starts with `text/` will now be treated the same as `text/html` already was—they will return the `response.text` attribute from the [httpx Response](https://www.python-httpx.org/api/#response). Thanks to @fdintino for the initial implementation, and thanks for the discussions from @kairntech, @rubenfiszel, and @antoneladestito. Closes openapi-generators#797 and openapi-generators#821. #### Support `application/octet-stream` request bodies Endpoints that accept `application/octet-stream` request bodies are now supported using the same `File` type as octet-stream responses. Thanks to @kgutwin for the implementation and @rtaycher for the discussion! PR openapi-generators#899 closes o 10000 penapi-generators#588 ### Fixes #### Remove useless `pass` statements from generated code Co-authored-by: GitHub <github-actions@github.com>
PreviousNext