-
-
Notifications
You must be signed in to change notification settings - Fork 228
feat: Add new client parameters: encoding #330
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
Conversation
Codecov Report
@@ Coverage Diff @@
## main #330 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 47 47
Lines 1398 1410 +12
=========================================
+ Hits 1398 1410 +12
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @dongfangtianyu! One small nitpick - I think using file_encoding
everywhere instead of encoding
is a bit clearer.
While I think this is still a useful CLI option, maybe utf-8 should be our default encoding anyways? What do you think @dbanty
openapi_python_client/cli.py
Outdated
@@ -116,6 +116,7 @@ def generate( | |||
url: Optional[str] = typer.Option(None, help="A URL to read the JSON from"), | |||
path: Optional[pathlib.Path] = typer.Option(None, help="A path to the JSON file"), | |||
custom_template_path: Optional[pathlib.Path] = typer.Option(None, **custom_template_path_options), # type: ignore | |||
encoding: Optional[str] = typer.Option(None, help="Set file encoding for client files"), # type: ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
encoding: Optional[str] = typer.Option(None, help="Set file encoding for client files"), # type: ignore | |
encoding: Optional[str] = typer.Option(None, help="Encoding used when writing generated files"), # type: ignore |
openapi_python_client/cli.py
Outdated
@@ -116,6 +116,7 @@ def generate( | |||
url: Optional[str] = typer.Option(None, help="A URL to read the JSON from"), | |||
path: Optional[pathlib.Path] = typer.Option(None, help="A path to the JSON file"), | |||
custom_template_path: Optional[pathlib.Path] = typer.Option(None, **custom_template_path_options), # type: ignore | |||
encoding: Optional[str] = typer.Option(None, help="Set file encoding for client files"), # type: ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using an enum of choices would be better than an arbitrary string here... although unless someone has created an enum with every encoding we'll have to manually add supported encoding options. Not the end of the world IMO + gives us a bit more control over what we officially support.
Agreed.
I don't think there is any built in enum with available encodings, and it's probably possible to register different codecs somehow. I don't think we want to be in the business of trying to maintain or restrict a list, we support whatever Python supports. We could, however, add some validation here using something like codecs.getencoder to provide a useful error message to the user instead of just crashing when writing if the encoding is not supported. |
In general, we only use UTF-8, but we don't know whether users will use other codes,
May user want the operating system to decide codecs, need pass a What bothers me is that I haven't found a way to use the default value to gracefully deliver Maybe my idea is wrong, user need not use the |
I think the more obvious behavior to the user is to explicitly set an encoding default (UTF-8). I can't think of a scenario where having the system decide the codec is sustainable or reproducible. At least for me, I tend to generate clients in CI after testing locally. If CI and local had different system codecs it would be failing without me knowing why which could be frustrating. |
Hi, @dbanty , I know where our differences are. Now, my way of using it is to move the generated folder directly into the existing test project. Is the right way to use it is to think of the client as a separate Python package? Only import and call, should not be modified |
1 similar comment
Hi, @dbanty , I know where our differences are. Now, my way of using it is to move the generated folder directly into the existing test project. Is the right way to use it is to think of the client as a separate Python package? Only import and call, should not be modified |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one more nitpick and then this will be good to go!
openapi_python_client/__init__.py
Outdated
@@ -44,10 +44,19 @@ class Project: | |||
project_name_override: Optional[str] = None | |||
package_name_override: Optional[str] = None | |||
package_version_override: Optional[str] = None | |||
|
|||
def __init__(self, *, openapi: GeneratorData, meta: MetaType, custom_template_path: Optional[Path] = None) -> None: | |||
file_encoding: str |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
file_encoding: str |
Don't need this at the class level
openapi_python_client/__init__.py
Outdated
self.openapi: GeneratorData = openapi | ||
self.meta: MetaType = meta | ||
self.encoding = file_encoding |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be self.file_encoding
everywhere
@dongfangtianyu there isn't necessarily a right or wrong way to use the package, however if I had to guess I would think most people use the client as a standalone python package and don't edit it much. That being said, obviously you are free to use it how you please and we aim to support all ways of using the project. I do think utf-8 encoding makes sense as a default - it is incredibly common and will work in 99% of use cases + fixes issues such as yours without any consequence for users who don't explicitly need utf-8. Worst come to worst a user can specify their own encoding if necessary thanks to this PR you've made! |
… default is UTF-8
If there are non-ASCII characters in openapi (eg: https://v1.api.tttt.one/openapi.json)

Garbled characters may appear in the generated client file.
To this end, add encoding parameter to cli,Similar problems can be ended by
--encoding=utf-8