[WIP] Add pluggable transport registry

[ad-m]

It is possible that built-in transports should also be rewritten in this way.

[coddingtonbear]

This isn't a bad pattern to follow! I had for a while considered refactoring the transports such that we could use setuptools' entry_points for defining new ones (this is how flake8, click, pylons, etc. handle registering plugins) . The upside of that is that packages adding support for new transports could be released and automatically detected without any effort. The downside, though, is that using entry_points requires that people implementing new transports write an installable package with its own setup.py file and associated baggage. Python packaging is a pain in general; so that is kind of a high bar.

Going this route does let people circumvent that whole set of problems, and although there are limitations of this approach (the module registering itself must somehow be imported before it'll appear in the registry) -- there're common patterns used in Django for handling that class of problems already given that use of signals already requires that. So, I think you've made the right choice!

[ad-m]

@coddingtonbear , in up-to-date django there is AppConfig.ready which is recommended way to register signals (we miss that in our docs).

[coddingtonbear]

Yeah -- it wouldn't at all surprise me if our docs don't mention AppConfig.ready. I'm pretty sure django-mailbox predates that feature entirely! Back when I was writing this, the recommended pattern was still that signals be either imported by models.py or included there directly.