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
⬆️ Upgrade Starlette to 0.14.2, including internal UJSONResponse
migrated from Starlette
#2335
Conversation
a424b92
to
a8600f9
Compare
Codecov Report
@@ Coverage Diff @@
## master #2335 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 243 244 +1
Lines 7419 7276 -143
==========================================
- Hits 7419 7276 -143
Continue to review full report at Codecov.
|
Will this be merged soon? It is problematic that server breaks when installing both FastAPI and Starlette latest versions. |
This needs to be refactored when the PR is accepted: https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Python/fastapi Just posting here as a note for people in the future 😮 |
|
Hey @tiangolo, anything that needs to be resolved before we can merge this? |
@hanneskuettner try force the CI to re-run so that the tests pass. It is weird, but maybe it is not being reviewed because of it. |
The issue on the |
a8600f9
to
3b10ea3
Compare
📝 Docs preview for commit 3b10ea3c052e18ea464e88d50df29565c7f756c1 at: https://5fce368cf47f96bc6bba1226--fastapi.netlify.app |
Still need for supporting ujson? The reason why starletter removed ujson from core looks like reducing 3rd party dependency. Supporting a lot of 3rd libraries maybe lead to messsy situation. How about writing custom response in docs (maybe not documented)? like this encode/starlette#1047 |
@yareyaredesuyo Sure thing. I personally agree with removing We could open up an issue and discuss removing both of them maybe. |
This change, reimplementing |
Please consider upgrading starlette to 0.14.2. |
Seems fairly straight forward, any reason this is not merged and released yet? |
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.
I recommend going ahead with this after pinning starlette to 0.14.2 instead of 0.14.1 -- there is a fix for Python 3.8+ when debug is set (starlette does not show/log tracebacks properly without the fix).
@tiangolo hi! for version 0.63 debug response is broken in python 3.8 due to starlette bug. Could you please schedule this PR for release? |
3b10ea3
to
049a91a
Compare
📝 Docs preview for commit 049a91a at: https://60420e885c368bdc16c48184--fastapi.netlify.app |
Rebased onto current master and bumped starlette to 0.14.2. |
This is awesome. Thanks @hanneskuettner! Any chance we could change the version pin to not be so strict? For instance, use edit: maybe don't even specify a max version? I get that it's recommended that one pin versions explicitly when deploying an application, but a library's requirements spec isn't really the best place to do that (pipenv, poetry and conda are tools that manage lock files for python projects). IMO, the library should specify a minimum supported version for any dependencies and let clients decide how far ahead works for them. If some dependency ships a breaking change, then we can come back and put an upper limit in this project's requirements (or better yet, adapt to the breaking change). |
Still not merging? |
@jcwilson I also thought about relaxing the pinned version, I found however this previous attempt and @tiangolo advocated against relaxing due to tight coupling to starlette internals. @tiangolo any change in opinion on that front? |
Thanks for pointing that out. I'd still like to advocate for not being so strict, but if doing would delay this PR at all, I'd be glad to argue for it in a follow-up PR. However, I can see how the strict version pinning can make it easier to ensure that the docs remain consistent with expected behavior since much of the FastAPI documentation is actually starlette documentation. |
Any news on this? Would be really nice to have this merged. @hanneskuettner @jcwilson |
TBH doesn't look like there's been a lot of activity in the repo at all in the last few months. |
There's no need for spamming. @tiangolo will eventually see this PR. Also, for those who don't know, he announced publically that he'll dedicate more time to FastAPI (and other OS projects) starting this month. So, you can expect this to be reviewed by him in the next weeks. |
@tiangolo any update on this? As this is causing issues for so many people and holding things up for people and distros. If this could get merged ASAP even without a release least people could then point to the master git branch |
UJSONResponse
migrated from Starlette
Awesome, thank you @hanneskuettner ! 🎉 Thanks for all the care adding all the details, explanations, and info. Thanks for the discussion everyone! And thanks for the help @Kludex and @Mause 🙇 🍰 Indeed, I had very little time for open source during the last months. 😔 But I recently resigned from my job to be able to dedicate a high percentage of my working time to FastAPI and the other open source projects, while doing some consultancy to make it all sustainable, so I'll be able to work a lot more no all this. 🤓 🚀 This will be available in FastAPI |
See related ticket: tiangolo/fastapi#2335
starlette 0.14.1 includes a fix for users that want to use the
@requires
decorator from theAuthenticationMiddleware
on FastAPI routes.Breaking in starlette changes as far as I can see are:
UJSONResponse
was removed from the core as per this issue, they added documentation on how to implement custom JSON serialization.UJSONResponse
is explicitly exported in FastAPI and should either be removed to follow starlette or added back in as done withORJSONResponse
. For this PR I chose to add a customUJSONResponse
and add test cases.Is there any reason it was hard locked to 13.6 I am not aware of or is it as straightforward as updating the requirement?