#37161: Implement a system check for no default MAILERS configuration
-------------------------------------+-------------------------------------
Reporter: Jacob Walls | Owner: Bader
| Eddine Benhirt
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 Natalia Bidart):
Thank you everyone for the discussion. A few comments from my side:
> Jacob, this would be a release blocker for 7.0, right? Not for 6.1.
I actually think we should try to land this in 6.1 as a warning-level
system check, not an error. The goal is to give users advance notice and
encourage migration well before 7.0, where the deprecated settings are
removed.
> #35674 (accepted) will [...]
While I agree with Mike's assessment of that ticket, I am not expecting
much short-term progress there given the ongoing disagreement around the
implementation. From my perspective, it is effectively stalled for now, so
I would not rely on it as part of the `MAILERS` migration story.
> Avoiding noisy (deprecation) warnings [...]
I feel strongly that we should not "bother" projects (or reusable apps)
that do not use email at all. A project that never sends email should not
need to configure `MAILERS`, and it should not need to silence warnings or
system checks related to email. Likewise, reusable apps should not be
encouraged to define email configuration merely to satisfy a check.
For that reason, I would support a check only when `MAILERS` is explicitly
defined by the project. At that point, Django can reasonably assume the
project intends to use the email framework and validate the configuration
accordingly. In particular, warning when `MAILERS` is defined but does not
contain a `"default"` alias seems reasonable to me.
I am less convinced that we should add a separate system check for
projects still using explicit `EMAIL_*` settings, since those users should
already receive deprecation warnings. If we do want to add check for
these, perhaps these are the one that should target 7.0 only.
> None of the built-in tags seem to apply. I'm thinking we should add a
tag for mail?
+1 to adding a dedicated `mail` tag.
> #37166 (awaiting triage) is the other system check suggested in the DEP
I think we could fix both in this same ticket, unclear if we really need
two tickets, but I don't object either.
Hopefully this helps answers some of the questions.
--
Ticket URL: <https://code.djangoproject.com/ticket/37161#comment:15>
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/0107019ecceb1e1a-2bd22c64-d0b8-47f9-9e22-848b08f2daf3-000000%40eu-central-1.amazonses.com.
