Openapi-python-client

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.

Fixes

Remove spurious field_dict.update({}) for types without properties (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 959 which fixes 958 and 967.

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 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 940 fixes issue 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`.

Features

Export `Unset` types from generated `types.py` (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 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 922 macmoritz!

Fix lists within unions

Fixes 756 and 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

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.

Features

Support httpx 0.26 (913)