Skip to content

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

Merged
merged 8 commits into from
Feb 16, 2021

Conversation

dongfangtianyu
Copy link
Contributor

@dongfangtianyu dongfangtianyu commented Feb 8, 2021

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

To this end, add encoding parameter to cli,Similar problems can be ended by --encoding=utf-8

@codecov
Copy link

codecov bot commented Feb 8, 2021

Codecov Report

Merging #330 (e0a1392) into main (2d305dd) will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##              main      #330   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           47        47           
  Lines         1398      1410   +12     
=========================================
+ Hits          1398      1410   +12     
Impacted Files Coverage Δ
openapi_python_client/__init__.py 100.00% <100.00%> (ø)
openapi_python_client/cli.py 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2d305dd...e0a1392. Read the comment docs.

Copy link
Collaborator

@emann emann left a 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

@@ -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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

@@ -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
Copy link
Collaborator

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.

@dbanty
Copy link
Collaborator

dbanty commented Feb 8, 2021

maybe utf-8 should be our default encoding anyways?

Agreed.

Using an enum of choices would be better than an arbitrary string here

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.

@dongfangtianyu
Copy link
Contributor Author

In general, we only use UTF-8, but we don't know whether users will use other codes,

if encoding is not specified the encoding used is platform dependent

May user want the operating system to decide codecs, need pass a None to encoding,

What bothers me is that I haven't found a way to use the default value to gracefully deliver None

Maybe my idea is wrong, user need not use the None

@dbanty
Copy link
Collaborator

dbanty commented Feb 9, 2021

May user want the operating system to decide codecs, need pass a None to encoding,

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.

@dongfangtianyu
Copy link
Contributor Author

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.
So I want the client's file code to be consistent with the original file code of the test project -- determined by the operating system

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
If so, then UTF-8 is very appropriate.

1 similar comment
@dongfangtianyu
Copy link
Contributor Author

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.
So I want the client's file code to be consistent with the original file code of the test project -- determined by the operating system

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
If so, then UTF-8 is very appropriate.

Copy link
Collaborator

@emann emann left a 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!

@@ -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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
file_encoding: str

Don't need this at the class level

self.openapi: GeneratorData = openapi
self.meta: MetaType = meta
self.encoding = file_encoding
Copy link
Collaborator

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

@emann
Copy link
Collaborator

emann commented Feb 15, 2021

@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!

@emann emann enabled auto-merge (squash) February 16, 2021 20:01
@emann emann merged commit 7f8d10e into openapi-generators:main Feb 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants