Add a new testconnections management command

[Loek van Gent]

Add a management command to check connection to mail server (without actually sending emails). This command can be extended later with testing other connections like caching ad maybe other settings.

Here's a snippet that would test a smtp connection

from django.core import mail
from django.core.mail.backends.smtp import EmailBackend

    def _check_mail_settings(self):
        connection = mail.get_connection()
        if isinstance(connection, EmailBackend):
            connection.open()

[John Moses]

Is this still needed with the sendtestemail command?

[Loek van Gent]

The idea is that this commands will test all kind of connections. This should only test if the mailserver is reachable and if you can log in with the given credentials, without actually sending emails.
We could later extend it with testing the settings/servers for chaching, celery etc.

[Alex Morozov]

Does it make sense to extend the ​system check framework with this kind of functionality? If that's ok, I'd try to draft some code.

[Tim Graham]

Currently the system check framework is limited to static code analysis. Adding a new option like check --conections could work. I think these checks shouldn't run if that option isn't specified though.

[Alex Morozov]

@timgraham, thank you. Will have a closer look on this. Should the check --connections test only connections as its name implies, or maybe we should rename the option? My English is pretty poor, but wouldn't something like --with-connections be more clear?

[Tim Graham]

I think testing only connections is fine as it's a fundamentally different type of check from the static code checks but this is subject to the implementation, what checks we actually add, and what others think is best.

[Shai Berger]

What do we gain by folding it into the system checks framework? How is that better than a separate command?

Also, is this intended mostly for "local" connections (mail, database, job-queue broker) or are "remote" connections (OAuth providers, other APIs) also on the plate?

[Tim Graham]

One advantage of the the checks framework is that it makes it easy for users to register new checks if they want to check parts of their infrastructure that Django core doesn't know about.

I don't know the answer to your second question. I have thought that it might be better to start this as a third-party project to allow it to iterate more quickly, see if it gains any traction and if so, how exactly users end up using it.

[Alex Morozov]

@shaib, the whole "checks" framework seems to me to be a registry of various checks of "system health". Remote dependencies are (for me) the perfect fit for that. Introducing another command seems to be an real cognitive overhead.
As for the "remote" connections - I'm quite fine with that, it would help a lot on deploy. Though such kind of checks surely should be warnings, not errors.

@timgraham, speaking of starting this as a separate project - I'm not sure there's an easy way to register those tests as 'checks', while having the check framework skipping them for the 'common' run. And implementing a separate 'remote checks' registry (mostly copy-pasting the checks' code) looks like a total mess for me.

If we could mark some checks tags to be skipped at the plain run (more generic way of that "deploy" thing), would it be of help?

[Tim Graham]

Making the checks framework more extensible does seem interesting but may be a bit tricky and will obviously delay being able to release this as a third-party app until the next Django feature release. It might involve a little copy/pasting from Django, but I think it should be straightforward to mimic a simple version of Django's check registry in a third-party app/command.

[Alex Morozov]

@timgraham, I've got your reservations, thank you. I'll try to draft a third-party package, or to make use of some existing one.

P.S. After a bit of googling, I have found ​an interesting package. Do you know any of similar libraries, maybe, even more generic?

[Mariusz Felisiak]

There are already 3rd-party packages that check the status of various connections e.g. django-health-check. We need to reach a strong consensus on the DevelopersMailingList before incorporating them into Django.