-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Interest in async support? #3546
Comments
Honestly, I don't see this as a priority at this stage. Unfortunately, due to the way Python async is designed (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/) this would basically boil down to doubling all the interfaces, providing e.g. each adapter method with a sync and async variant. Now, while this certainly can be achieved, I think cleaning up interfaces first, perhaps even reaching a 1.0, before doubling the work is more important. |
I was just about to create this issue. Honestly now I'm stuck, because I need an async version of this. |
@Retr02332 if you are extending allauth in some way to work in an async context, then you need to make use of sync_to_async. If you come up with a common problem and solution, perhaps post here for others. |
I found a major problem with django-allauth and django 5's support of async views cancellation. This might interest you all: |
See above mentioned -- now closed -- issues. Apparently, people are already running in async contexts. So the question is, what is currently still missing in order to close this issue? |
#3612 got us on our update to 0.60.1/current. We were on 0.54.0 with Django 4.2 running ASGI with no fuss, but not really fully leveraging async for much as other packages also face similar async adoption pains. Just being compatible enough to run in that space, even if it's spoiling/blocking is enough of a first step, imo. "ASGI compatible but not optimized/recommended" sure seems close if we were running it that way for so long. |
I think the use cases are:
If I could wave a magic wand and make allauth fully async on all io related functions, I would. It's not easy. Django ORM itself doesn't even utilize database driver async and instead wraps it in sync_to_async which causes it to execute in a thread. It's rather a pain to write async and sync versions of everything. It would be painful to instead convert all io functions to async and tell end users it's a breaking change. I would keep this issue open but consider it a long term task without any urgency. |
Hello, Django's async support is decent these days. I'm curious if you would accept a pull request for async support? It would open up a lot of questions, but first I'd like to know if there is any interest at all.
The io used in allauth looks to be ORM queries and some http requests. The potential benefit, in brief, is that async would allow the server administrator to serve more with less system resources. An additional benefit may be that a new django application today could choose to use an async-first approach and anything incompatible becomes harder to work with when extending. As always - thanks for this project - I love the recent updates!
The text was updated successfully, but these errors were encountered: