Hello, I'd like to to chime in quickly as I'm responsible for this boilerplate (see this talk <https://myks.org/data/20140513-DjangoCon-App-loading.pdf>, slide 33).
This is really a question of convention vs. configuration. Django tends to prefer configuration over convention, because there's value is seeing what happens just when you read the code, especially when you read other people's code. Other frameworks take a different approach to this, perhaps because they care more about writing less code or because they focus more on the "single person team" use case. As Adam points out in his reply on the forum, Django autoloads models, admins, and apps. Most Django users and maintainers love models and admins; hopefully they admit that apps solve a problem that needed solving. At the same time, many of them are also skeptical of signals, having witnessed excessive use of signals in projects, usually in the name of decoupling, and sometimes because the person writing the code didn't find any other way to break an import loop. (It's easy: import modules instead of objects, then reference all objects as mymodule.MyObject, and you're good.) Signals result in inversion of control: you declare a function call in the callee rather than in the caller. This tends to make it more difficult to figure out what the code is doing. In my opinion, the only valid use case for signals is when the code sending the signal is provided by a third-party library that you don't control. If you have signals inside your project, I'd suggest refactoring them to good old function calls. Then perhaps you have fewer signals and don't feel such a need to autoload them. If you still have too many, Adam's suggestion works :-) -- Aymeric. > On 14 Sep 2021, at 17:37, 'Adam Johnson' via Django developers (Contributions > to Django itself) <django-developers@googlegroups.com> wrote: > > I've replied on the forum. > > On Tue, 14 Sept 2021 at 13:21, Roxane Bellot <roxane.bel...@gmail.com > <mailto:roxane.bel...@gmail.com>> wrote: > > > Hi guys ! > > First of all, i’m new here, so if this issue has already been discussed or if > here is not the place to talk about it (I also opened a forum post > <https://forum.djangoproject.com/t/load-signals-automatically/9666>) please > don’t hesitate to tell me. Also, please be aware English is not my first > language. > > I would want to discuss about signals and how they are loaded in Django. > > Very often, i create my signals.py, write my signal and wonder for a while > why it does not work. Of course, the file is not imported and so never even > read by python ! > So i create an apps.py, on this template : > > from django.apps import AppConfig > > > class CustomAppConfig(AppConfig): > name = "app.subapp" > > def ready(self): > import app.subapp.signals > > I would like to sugest importing signals.py automatically at app loading > (maybe django.apps.config.AppConfig.ready() ?) > > Pros > > no more wandering for hours what is the problem here > no more boilerplate apps.py everywhere > Cons > > file with signals would have to be named signals.py > maybe some rely on the file being imported when they decided ? (don’t see a > use case here, specially when loading signals does not equals activating them) > Alternatives > > If loading (and so activating) signals is too mush of a change, maybe others > solutions will fix my problem. For know, all I can think of : > > Log if a signals.py file is detected but the AppConfig is not overriden (but > we would not know if imported elsewhere) > Log how many signals are detected for the app (but from a dozen apps the log > will be too heavy to be read) > not really an alternative, but the loading could be conditionnal to a > project-wide setting > i would like to know if this would benefits others (I think so) and if it is > worthy of filing an Issue (as a developper I may find time to dev on it if > needed) > > > > Looking forward to reading from you, > > Roxane Bellot > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAAvJ%2BFzx%3DFZ01BvBhEtH8SOZQA3imM4q3j1FNA7EF6ec1BKrPA%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CAAvJ%2BFzx%3DFZ01BvBhEtH8SOZQA3imM4q3j1FNA7EF6ec1BKrPA%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMyDDM1%2B-MT4UXH5gAh6fPq1GuGjvC2gmU22VBrbXWONXKquGg%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CAMyDDM1%2B-MT4UXH5gAh6fPq1GuGjvC2gmU22VBrbXWONXKquGg%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5F1B7917-34C8-4572-9C39-3AC896081AE8%40polytechnique.org.
