Skip to content
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

Closed
AlexandreODelisle opened this issue Feb 17, 2022 · 4 comments · Fixed by #1139
Closed

Duplicate Key Error during parser/properties/enum #587

AlexandreODelisle opened this issue Feb 17, 2022 · 4 comments · Fixed by #1139
Labels
🐞bug Something isn't working
Milestone

Comments

@AlexandreODelisle
Copy link

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 and Add )

    values = EnumProperty.values_from_list(value_list)
  File "/home/adelisle/.local/lib/python3.8/site-packages/openapi_python_client/parser/properties/enum_property.py", line 61, in values_from_list
    raise ValueError(f"Duplicate key {key} in Enum")
ValueError: Duplicate key ADD in Enum

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):

  • OS: WSL2 Ubuntu 20.04
  • Python Version: 3.8.10
  • openapi-python-client version 0.11.1

Additional context
Line forcing KEY in uppercase.

It might be the proper behavior, I am just wondering, why GitHub Spec is not parsable.

@AlexandreODelisle AlexandreODelisle added the 🐞bug Something isn't working label Feb 17, 2022
@dbanty
Copy link
Collaborator

dbanty commented Feb 17, 2022

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).

@dbanty dbanty added this to the 0.11.2 milestone Feb 17, 2022
@dbanty dbanty modified the milestones: 0.11.2, 0.12.0 May 1, 2022
@wadinj
Copy link

wadinj commented Jul 25, 2022

Any plan to include this fix into the next release ?

@dbanty
Copy link
Collaborator

dbanty commented Aug 8, 2022

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 😓.

@emosenkis
Copy link
Contributor

Another potential solution is #1114

@knope-bot knope-bot bot mentioned this issue Oct 20, 2024
github-merge-queue bot pushed a commit that referenced this issue Oct 20, 2024
> [!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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants