Skip to content

Releases: openapi-generators/openapi-python-client

0.21.5 (2024-09-07)

07 Sep 22:09
90e0954
Compare
Choose a tag to compare

Features

Improved property-merging behavior with allOf

When using allOf to extend a base object type, openapi-python-client is now able to handle some kinds of modifications to an existing property that would have previously caused an error:

  • Overriding attributes that do not affect validation, such as description.
  • Combining properties that this generator ignores, like maxLength or pattern.
  • Combining a generic numeric type with int (resulting in int).
  • Adding a format to a string.
  • Combining any with a specific type (resulting in that specific type).
  • Adding or overriding a default

Note

pattern and max_length are no longer fields on StringProperty, which may impact custom templates.

This also fixes a bug where properties of inline objects (as opposed to references) were not using the
merge logic, but were simply overwriting previous definitions of the same property.

Fixes

  • Allow default values for properties of Any type

Produce valid code for an object that has no properties at all

Fixed by PR #1109. Thanks @eli-bl!

0.21.4 (2024-08-25)

25 Aug 06:41
04b30a9
Compare
Choose a tag to compare

Fixes

Correctly resolve references to a type that is itself just a single allOf reference

PR #1103 fixed issue #1091. Thanks @eli-bl!

Allow OpenAPI 3.1-style exclusiveMinimum and exclusiveMaximum

Fixed by PR #1092. Thanks @mikkelam!

Add missing cast import when using const

Fixed by PR #1072. Thanks @dorcohe!

Support const booleans and floats

Fixed in PR #1086. Thanks @flxdot!

0.21.3 (2024-08-18)

18 Aug 22:02
aa9f280
Compare
Choose a tag to compare

Features

  • update Ruff to >=0.2,<0.7 (#1097)

0.21.2 (2024-07-20)

20 Jul 19:05
ed5e908
Compare
Choose a tag to compare

Features

  • Update to Ruff 0.5

0.21.1 (2024-06-15)

15 Jun 19:48
cb32c30
Compare
Choose a tag to compare

Features

Support request body refs

You can now define and reuse bodies via refs, with a document like this:

paths:
/something:
post:
requestBody:
"$ref": "#/components/requestBodies/SharedBody"
components:
requestBodies:
SharedBody:
content:
application/json:
schema:
type: string

Thanks to @kigawas and @supermihi for initial implementations and @RockyMM for the initial request.

Closes #633, closes #664, resolves #595.

Fixes

  • Indent of generated code for non-required lists. Thanks @sfowl! (#1050)
  • Parsing requestBody with $ref (#633)

0.21.0 (2024-06-08)

08 Jun 21:27
8591f15
Compare
Choose a tag to compare

Breaking Changes

Removed the update command

The update command is no more, you can (mostly) replace its usage with some new flags on the generate command.

If you had a package named my-api-client in the current working directory, the update command previously would update the my_api_client module within it. You can now almost perfectly replicate this behavior using openapi-python-client generate --meta=none --output-path=my-api-client/my_api_client --overwrite.

The only difference is that my-api-client would have run post_hooks in the my-api-client directory,
but generate will run post_hooks in the output-path directory.

Alternatively, you can now also run openapi-python-client generate --meta=<your-meta-type> --overwrite to regenerate
the entire client, if you don't care about keeping any changes you've made to the generated client.

Please comment on discussion #824
(or a new discussion, as appropriate) to aid in designing future features that fill any gaps this leaves for you.

Features

Added an --output-path option to generate

Rather than changing directories before running generate you can now specify an output directory with --output-path.
Note that the project name will not be appended to the --output-path, whatever path you specify is where the
generated code will be placed.

Added an --overwrite flag to generate

You can now tell openapi-python-client to overwrite an existing directory, rather than deleting it yourself before
running generate.

0.20.0 (2024-05-18)

18 May 19:51
7af00ce
Compare
Choose a tag to compare

Breaking Changes

const values in responses are now validated at runtime

Prior to this version, const values returned from servers were assumed to always be correct. Now, if a server returns
an unexpected value, the client will raise a ValueError. This should enable better usage with oneOf.

PR #1024. Thanks @peter-greenatlas!

Switch YAML parsing to 1.2

This change switches the YAML parsing library to ruamel.yaml which follows the YAML 1.2 specification.
There are breaking changes from YAML 1.1 to 1.2,
though they will not affect most use cases.

PR #1042 fixes #1041. Thanks @rtaycher!

Features

Fixes

Fix nullable and required properties in multipart bodies

Fixes #926.

Warning

This change is likely to break custom templates. Multipart body handling has been completely split from JSON bodies.

0.19.1 (2024-03-27)

27 Mar 00:50
30665ea
Compare
Choose a tag to compare

Features

Add config option to override content types

You can now define a content_type_overrides field in your config.yml:

content_type_overrides:
application/zip: application/octet-stream

This allows openapi-python-client to generate code for content types it doesn't recognize.

PR #1010 closes #810. Thanks @gaarutyunov!

Fixes

Add aliases to Client for pyright

This should resolve incompatibilities between the generated Client class and the pyright type checker.

PR #1009 closes #909. Thanks @patrick91!

0.19.0 (2024-03-06)

06 Mar 02:45
0399271
Compare
Choose a tag to compare

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 #989 implements #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 #986 fixed issue #976. Thanks @harabat!

Warning

This change may break custom templates, see this diff
if you have trouble upgrading.

0.18.0 (2024-02-22)

22 Feb 18:09
c28226e
Compare
Choose a tag to compare

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 #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 (#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 #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:

type: "object"
properties:
MixedCase:
type: "string"
mixedCase:
type: "string"

Would generate a class like this:

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:

class MyModel:
MixedCase: str
mixedCase: str