Support binary request bodies for endpoints#899
Support binary request bodies for endpoints#899dbanty merged 11 commits intoopenapi-generators:mainfrom
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #899 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 49 49
Lines 1932 1940 +8
=========================================
+ Hits 1932 1940 +8 ☔ View full report in Codecov by Sentry. |
|
I'm not sure what to do with the "1 missing line" from the Codecov report. The line is from a stub function in a Protocol used for type checking (see some of the examples here: https://docs.python.org/3/library/typing.html#annotating-callable-objects) and the |
|
I think a |
|
Thanks for putting this together! I like the idea of deduplicating the body logic a bit, but I wonder if there's a way we can do it without |
# Conflicts: # openapi_python_client/parser/openapi.py
|
Okay, I think I've decided that the way I want to fix this in the future will coincide with fixing support for multiple content-types—but that can wait until later since it will be a big change. I did open #900 as a draft of what that could look like, if you want to take a look 😁 |
This PR was created by Knope. Merging it will create a new release ### Breaking Changes #### Switch from Black to Ruff for formatting `black` is no longer a runtime dependency, so if you have them set in custom `post_hooks` in a config file, you'll need to make sure they're being installed manually. [`ruff`](https://docs.astral.sh/ruff) is now installed and used by default instead. #### Use Ruff instead of isort + autoflake at runtime `isort` and `autoflake` are no longer runtime dependencies, so if you have them set in custom `post_hooks` in a config file, you'll need to make sure they're being installed manually. [`ruff`](https://docs.astral.sh/ruff) is now installed and used by default instead. ### Features #### Support all `text/*` content types in responses Within an API response, any content type which starts with `text/` will now be treated the same as `text/html` already was—they will return the `response.text` attribute from the [httpx Response](https://www.python-httpx.org/api/#response). Thanks to @fdintino for the initial implementation, and thanks for the discussions from @kairntech, @rubenfiszel, and @antoneladestito. Closes #797 and #821. #### Support `application/octet-stream` request bodies Endpoints that accept `application/octet-stream` request bodies are now supported using the same `File` type as octet-stream responses. Thanks to @kgutwin for the implementation and @rtaycher for the discussion! PR #899 closes #588 ### Fixes #### Remove useless `pass` statements from generated code Co-authored-by: GitHub <[email protected]>
Resolves #588.
Thanks for a great tool! I hope this is compatible with the active work going on in #897.