Spec errors #922
Comments
|
If I remove the path Don't know how this works/sticks together. |
|
Alright, there are at least 3 issues I've found so far 😁:
So, if you remove the bits that cause errors for 2 & 3 (like the modified attached spec), you can use the new branch on #923 (which somewhat supports bool enums) to generate the client now 😁. |
This PR was created by Knope. Merging it will create a new release ### 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 Co-authored-by: GitHub <[email protected]>
|
Nice! Thanks for fixing boolean enums, works like a charm. In total, the interesting point is, that the other generator mentioned above can work with both remaining issues. Maybe we can get some information there. |
|
I checked the openapi spec of sentry again and ensured that case 2 only occures in this endpoint. I opened an upstream issue for that (getsentry/sentry#62717). Regarding point 3: It seems that |
|
FYI: Sounds like Sentry will fix the schema, which resolves our point 2 (see above). |
|
I believe the only remaining issue (3 above, |
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 #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: ```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 <[email protected]>
Describe the bug
I am trying to create a python client for the sentry api by using this generator.
Not sure if this issue belongs here or to sentry (cause of they created the schema).
Other generators work fine with this schema. See below.
OpenAPI Spec File
https://github.com/getsentry/sentry-api-schema/blob/main/openapi-derefed.json
Desktop (please complete the following information):
Additional context
Log
Working generator
OpenAPITools/openapi-generator
docker run --rm -v ${PWD}:/local openapitools/openapi-generator-cli generate -i /local/openapi.json -g python -o /local/out/python@benedikt-bartscher
The text was updated successfully, but these errors were encountered: