-
-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicate Key Error during parser/properties/enum #587
Comments
Well technically the values of an enum are case sensitive, the idiomatic way to represent an enum in Python is just to use the all caps representation of it. It hasn't come up until now where two words were spelled the same but with different casing being a unique value. Maybe in the case where we detect this, we simply abort the auto-renaming and instead use the less-Pythonic as-is name. So in this case it would generate something like this: class Operaions(str, Enum):
add = "add"
Add = "Add"
... That would unfortunately mean that adding a new enum variant could cause breaking changes in the generated client—but it's better than disallowing this feature since it's used in a popular API (GitHub). |
Any plan to include this fix into the next release ? |
Unfortunately, I don't have much time to dedicate to this project right now—the little bit of open source time I have is focused elsewhere. If someone contributes this as a PR it'll happen sooner—but I'm having trouble even keeping up with the PRs that are open 😓. |
Another potential solution is #1114 |
> [!IMPORTANT] > Merging this pull request will create this release ## Features - update Ruff to >=0.2,<0.8 (#1137) - Add UUID string format. Thanks @estyrke! (#1140) - Support OpenAPI 3.1 prefixItems property for arrays. Thanks @estyrke! (#1141) ### Add `literal_enums` config setting Instead of the default `Enum` classes for enums, you can now generate `Literal` sets wherever `enum` appears in the OpenAPI spec by setting `literal_enums: true` in your config file. ```yaml literal_enums: true ``` Thanks to @emosenkis for PR #1114 closes #587, #725, #1076, and probably many more. Thanks also to @eli-bl, @expobrain, @theorm, @chrisguillory, and anyone else who helped getting to this design! ## Fixes - Typo in docstring (#1128) ### Use literal value instead of `HTTPStatus` enum when checking response statuses Python 3.13 renamed some of the `HTTPStatus` enum members, which means clients generated with Python 3.13 may not work with older versions of Python. This change stops using the `HTTPStatus` enum directly when checking response statuses. Statuses will still be checked for validity at generation time, and transformed into `HTTPStatus` _after_ being checked at runtime. This may cause some linters to complain. Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>
Describe the bug
GitHub OpenAPI Descriptor parsing
It seems we can not parse the GitHub OpenAPI since in the SCIM emu we have twice the value (
add
andAdd
)To Reproduce
Steps to reproduce the behavior:
openapi-python-client generate --url https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json\?_sm_au_\=iHVj504RWD4Fn7kPLVN2jKsTtN4QF
Expected behavior
I would have thought GitHub Open API would have been parsable.
OpenAPI Spec File
https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json?_sm_au_=iHVj504RWD4Fn7kPLVN2jKsTtN4QF
You can lookup for
"ADD"
Desktop (please complete the following information):
Additional context
Line forcing KEY in uppercase.
openapi-python-client/openapi_python_client/parser/properties/enum_property.py
Line 57 in 199a8f9
It might be the proper behavior, I am just wondering, why GitHub Spec is not parsable.
The text was updated successfully, but these errors were encountered: