Tags: linkdd/openapi-python-client
Tags
chore: prepare release 0.19.0 (openapi-generators#990) This PR was created by Knope. Merging it will create a new release ### Breaking Changes #### Update PDM metadata syntax Metadata generated for PDM will now use the new `distribution = true` syntax instead of `package-type = "library"`. New packages generated with `--meta pdm` will require PDM `2.12.0` or later to build. ### Features #### Add response content to `UnexpectedStatus` exception The error message for `UnexpectedStatus` exceptions will now include the UTF-8 decoded (ignoring errors) body of the response. PR openapi-generators#989 implements openapi-generators#840. Thanks @harabat! ### Fixes #### Allow hyphens in path parameters Before now, path parameters which were invalid Python identifiers were not allowed, and would fail generation with an "Incorrect path templating" error. In particular, this meant that path parameters with hyphens were not allowed. This has now been fixed! PR openapi-generators#986 fixed issue openapi-generators#976. Thanks @harabat! > [!WARNING] > This change may break custom templates, see [this diff](https://github.com/openapi-generators/openapi-python-client/pull/986/files#diff-0de8437b26075d8fe8454cf47d8d95d4835c7f827fa87328e03f690412be803e) > if you have trouble upgrading. Co-authored-by: GitHub <github-actions@github.com>
chore: prepare release 0.18.0 (openapi-generators#975) This PR was created by Knope. Merging it will create a new release ### Breaking Changes #### For custom templates, changed type of endpoint parameters **This does not affect projects that are not using `--custom-template-path`** The type of these properties on `Endpoint` has been changed from `Dict[str, Property]` to `List[Property]`: - `path_parameters` - `query_parameters` - `header_parameters` - `cookie_parameters` If your templates are very close to the default templates, you can probably just remove `.values()` anywhere it appears. The type of `iter_all_parameters()` is also different, you probably want `list_all_parameters()` instead. #### Updated generated config for Ruff v0.2 This only affects projects using the `generate` command, not the `update` command. The `pyproject.toml` file generated which configures Ruff for linting and formatting has been updated to the 0.2 syntax, which means it will no longer work with Ruff 0.1. #### Updated naming strategy for conflicting properties While fixing openapi-generators#922, some naming strategies were updated. These should mostly be backwards compatible, but there may be some small differences in generated code. Make sure to check your diffs before pushing updates to consumers! ### Features #### support httpx 0.27 (openapi-generators#974) ### Fixes #### Allow parameters with names differing only by case If you have two parameters to an endpoint named `mixedCase` and `mixed_case`, previously, this was a conflict and the endpoint would not be generated. Now, the generator will skip snake-casing the parameters and use the names as-is. Note that this means if neither of the parameters _was_ snake case, neither _will be_ in the generated code. Fixes openapi-generators#922 reported by @macmoritz & @benedikt-bartscher. #### Fix naming conflicts with properties in models with mixed casing If you had an object with two properties, where the names differed only by case, conflicting properties would be generated in the model, which then failed the linting step (when using default config). For example, this: ```yaml type: "object" properties: MixedCase: type: "string" mixedCase: type: "string" ``` Would generate a class like this: ```python class MyModel: mixed_case: str mixed_case: str ``` Now, neither of the properties will be forced into snake case, and the generated code will look like this: ```python class MyModel: MixedCase: str mixedCase: str ``` Co-authored-by: GitHub <github-actions@github.com>
chore: prepare release 0.17.3 (openapi-generators#970) This PR was created by Knope. Merging it will create a new release ### Fixes #### Remove spurious field_dict.update({}) for types without properties (openapi-generators#969) #### Fix invalid type check for nested unions Nested union types (unions of unions) were generating `isinstance()` checks that were not valid (at least for Python 3.9). Thanks to @codebutler for PR openapi-generators#959 which fixes openapi-generators#958 and openapi-generators#967. Co-authored-by: GitHub <github-actions@github.com>
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 openapi-generators#588 ### Fixes #### Remove useless `pass` statements from generated code Co-authored-by: GitHub <github-actions@github.com>
PreviousNext