#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):
Replying to [comment:18 Johanan Oppong Amoateng]:
> What is the updates on this? I would want to tag myself and work on it
but i want to know the status whether Jacob Rief is still working on it
I believe Jacob Rief's PR is actually quite close—with the caveat that
(for a feature of this scope) "quite close" will likely still involve ''a
lot'' of work to get over the finish line. There are (I think) a couple of
mechanical issues and at least a couple of design decisions needed to move
this forward.
The mechanical issues:
- The PR needs to be rebased and conflicts resolved with the current code
on main.
- The PR has exceeded the number of commits and comments where GitHub's PR
review is usable. It would help to squash and open a new PR.
The design decisions:
A. To what extent do we want to support mixing new EMAIL_PROVIDERS
settings with deprecated EMAIL_BACKEND and EMAIL_HOST/USER/etc. settings?
[[BR]][[BR]]My suggestion would be it's ''all or nothing:'' once a
settings file contains EMAIL_PROVIDERS, the user has opted into the new
approach and any attempt to set ''or access'' the old EMAIL_BACKEND,
EMAIL_HOST, etc. becomes a hard error (not just a deprecation warning).
One implication is users would need to wait to switch to EMAIL_PROVIDERS
until ''all'' email backends they use have been updated to be providers-
aware, which would impact anyone using a "wrapper" email backend like
django-celery-email or django-mailer.
[[BR]][[BR]](More detail in
[https://github.com/django/django/pull/18421#pullrequestreview-2624473570
this PR comment] and the ones following, plus several related suggested
edits.)
B. Can we require that (Django's built-in) EmailBackend instances ''must''
be obtained by calling mail.get_connection(), or do we need to continue
allowing code to construct them directly?
[[BR]][[BR]]If we can require get_connection(), it simplifies the
backwards compatibility code in each EmailBackend somewhat. But it
requires updating nearly all of Django's existing EmailBackend tests,
which tend to call the constructor directly. (The current PR includes most
of those test updates; we'd likely want to pull them into a separate
"refs" commit first to prove they run correctly before this change.)
[[BR]][[BR]]The relevant docs start at
[https://docs.djangoproject.com/en/6.0/topics/email/#obtaining-an-
instance-of-an-email-backend Obtaining an instance of an email backend]:
"The `get_connection()` function in `django.core.mail` returns an instance
of the email backend that you can use." But they go on to document
available options for backends.smtp.EmailBackend() using the class
constructor format.
[[BR]][[BR]]I don't know whether that means we have documented
smtp.EmailBackend as a class, so the constructor must remain callable for
backwards compatibility. Or if it was just a convenient docutils syntax
for describing SMTP EmailBackend options that can be used as keywords to
get_connection(). (I can't imagine why real-world code would want to call
an EmailBackend constructor directly rather than going through
get_connection().)
C. I think there was also some question about maybe deprecating the
`backend` param to get_connection(). Or how and where to support new
provider alias params alongside existing `connection` params in other
django.core.mail APIs. (But I'm blanking on the details right now.)
(I'm hoping to have some time to look at this again more closely next
year, probably late January at the earliest.)
--
Ticket URL: <https://code.djangoproject.com/ticket/35514#comment:19>
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/0107019b4d403b9c-3dd44a93-1f65-45e3-bfc5-8a03f2251db4-000000%40eu-central-1.amazonses.com.
