#35514: Dictionary based EMAIL_PROVIDERS settings
-----------------------------+--------------------------------------
Reporter: Jacob Rief | Owner: Jacob Rief
Type: New feature | Status: assigned
Component: Core (Mail) | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------------------------
Comment (by Mike Edmunds):
Hi Natalia and Jacob W,
It's great to have some fresh eyes on this feature. And I agree it would
be valuable to get it into 6.1.
From my perspective, one really helpful thing would be to get consensus on
the proposed API changes and deprecation plans around the feature, before
too much more effort goes into code. I can try to draft a short spec if
that would be useful.
I really like Natalia's proposal to align `EMAIL_PROVIDERS` with the other
connection types. And I also need to digest it a bit. (Natalia, were you
thinking django.core.mail.providers could be built on the connection
handler utilities in django.utils.connection? Or just looking for parallel
APIs?)
One initial concern is that—as currently used—an EmailBackend instance is
usually ephemeral. It typically gets constructed, used for a single send
(or send_messages batch), and then abandoned to GC. Example in
[https://github.com/django/django/blob/f87c2055b45356378a7c2a020eb872352d20f85e/django/core/mail/__init__.py#L140-L149
send_mass_mail()]. There's nothing inherently wrong with keeping a backend
instance around longer and reusing it: they're meant to support that. (The
actual "connection" part of an EmailBackend instance is set up and torn
down in its open() and close() methods.) But backend instance reuse is not
the pattern in a lot of current code, so I'm not sure what problems we
might uncover.
Threading is a different matter: none of Django's current EmailBackend
implementations can be safely shared between threads, and I'm guessing
that applies to many third-party backends too.
Maybe `django.core.mail.providers["alias"]` should return a new
EmailBackend instance each time it's accessed, matching current
get_connection() behavior? Then as a follow-on feature we could add a way
for EmailBackend implementations to opt into caching (and indicate its
level of threading support).
(Another, minor concern is that `send_mail()` and `send_mass_mail()`
currently accept `auth_user` and `auth_password` params, which override
the default EMAIL_HOST_USER and EMAIL_HOST_PASSWORD for that one send. But
those params are already—and silently—broken when used together with
`connection`, so we could just make it an error to use them with a
`provider`.)
I'll put some thought into `get_connection()`. There are three use cases,
and I'm not sure how common the last two are:
* `get_connection()`
* `get_connection("path.to.some.EmailBackend")`
* `get_connection(..., extra="keyword args", are_passed="to the backend")`
--
Ticket URL: <https://code.djangoproject.com/ticket/35514#comment:23>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019c0d3f64bc-4119e726-2be2-4315-acfd-78b8a62793f1-000000%40eu-central-1.amazonses.com.
