Asyncio support?

[Andrew-Chen-Wang]

Any plans for asyncio support? I made a vendored version of the base console, and making PR to Django. Tracking: django/django#16744

I've made an SES v1 asyncio version. Happy to add unless you'd like to see the async one be merged first.

[medmunds]

I hadn't really thought about asyncio yet, but it certainly makes sense for calling ESP APIs.

I'd prefer to see async email land in Django core first, before adding it to Anymail, so that the new backend APIs are finalized and we could test against them. I suspect it would also help to get some real-world experience with an async version of Django's default SMTP EmailBackend. (Is there a reason your PR doesn't include the SMTP backend?)

A few additional things we'd need to figure out for Anymail:

• All of Anymail's backends other than SES use the requests package. Should Anymail use aiohttp directly, or httpx for better requests compatibility, or something else? (Whatever we pick needs to be stable, have a clear path for long-term maintenance, etc.)
• There are some places where requests data types have crept into Anymail's public API, and we'd need to figure out what happens to those if we're not using requests (or compatible) under the hood. (E.g.: REQUESTS_TIMEOUT, retry adapters, esp_response, probably others.)
• Async support should probably be an optional install. It would be nice to have a single async extras option, but I don't know if that's possible since different backends require different async packages. (pip install django-anymail[amazon_ses,mailgun,async] vs django-anymail[amazon_ses-async,mailgun-async].)
• Do we also want async views for tracking webhooks and inbound email?

Btw, Anymail support for SES v1 is deprecated and shouldn't really get any new features before we remove it later this year. (SES v2 is nearly identical to SES v1, just rearranges API names and params.)

[Andrew-Chen-Wang]

Is there a reason your PR doesn't include the SMTP backend?

Two reasons: From previous experience, Django team usually asks that I add a base implementation to get the design right. The other reason is that locally, most of the time, I usually use a console backend rather than MailHog, so I never got around to it.

All of Anymail's backends other than SES use the requests package. Should Anymail use aiohttp directly, or httpx for better requests compatibility, or something else? (Whatever we pick needs to be stable, have a clear path for long-term maintenance, etc.)

Either work as I've seen almost all project grows to a point where both are installed. HTTPX makes more sense if we want to reuse classes and logic flow.

There are some places where requests data types have crept into Anymail's public API, and we'd need to figure out what happens to those if we're not using requests (or compatible) under the hood. (E.g.: REQUESTS_TIMEOUT, retry adapters, esp_response, probably others.)

Suggestion of HTTPX probably will deprecate usage of requests.

Async support should probably be an optional install. It would be nice to have a single async extras option, but I don't know if that's possible since different backends require different async packages. (pip install django-anymail[amazon_ses,mailgun,async] vs django-anymail[amazon_ses-async,mailgun-async].)

I don't it's possible to just add a single async option unfortunately :( I do think forcing async specificity as a suffix is actually better though. It clarifies sync vs async.

Do we also want async views for tracking webhooks and inbound email?

Yes. Async ORM is already here, so I think it's time!

Btw, Anymail support for SES v1 is deprecated and shouldn't really get any new features before we remove it later this year. (SES v2 is nearly identical to SES v1, just rearranges API names and params.)

Vendored it back in February, right before v2 was released 😅

[medmunds]

So, I'm rethinking my earlier "I'd prefer to see async email land in Django core first." I actually think it would be fine for Anymail to introduce async email support ahead of Django. (And that might even provide some additional validation for your Django proposal.)

We'd probably want a big disclaimer that Anymail's async support should be considered experimental, and could change suddenly to match wherever Django ends up.

And a nice bonus is this would also backport the (proposed) Django 5.0 async django.core.mail functions to current Django versions. (Unless you were thinking of releasing that as a separate package along with async versions of the core backends.)

[Andrew-Chen-Wang]

This is great to hear! Definitely not going to be releasing a different package. I like the idea that anymail can be a backport of async versions of backends!

Unfortunately you've caught me right when I bricked my computer and don't have much time to contribute (hence lack of progress in the Django core PR). Happy to share my code to add to the repo! Will make a gist maybe?