For what it's worth, if we have some code that: a) is a new feature we want to ensure runs b) has no obvious, explicit place to place it and c) is trivially solved by .ready()
Then I start to think that practicality beats purity. Personally, I think we should still encourage the "explicit" approach where we recommend to users that they use 'path.to.AppConfig' and maybe one day deprecate not having an AppConfig - for external apps at least this ensures translatable admin, but in the mean time add an impure convention (which if we are going to do, I don't care which one we do). Explicit > Implicit yes, but if our choice is 'introduce an implicit convention, which we could one day deprecate' vs 'add some more import time side effect code' then I personally think we should go for the former. In Django 2.0 we do away with all the implicit importing and searching and you have to configure your AppConfig instances for management commands, template directories, static dirs, models, admin config... ;) Marc On 19 Jan 2014 12:52, "Russell Keith-Magee" <russ...@keith-magee.com> wrote: > > HI Marc, > > On Sun, Jan 19, 2014 at 5:52 PM, Marc Tamlyn <marc.tam...@gmail.com>wrote: > >> All of your proposed solutions require trying to import an apps.py module >> which may not exist. I know Aymeric was very much against this, especially >> as python imports have potential side effects, and we don't know what >> people might have in a apps module already. >> >> Anyways, configuration over convention and explicit better than implicit >> etc. >> >> It does mean that we can't put any required logic into AppConfig, but for >> example admin.autodiscover is fine as existing projects already call it in >> their urls.py (or wherever they moved it to), so there is no concern here, >> especially if we update the project template. >> >> The only other obvious contrib thing which would be nice to move is >> signal registration, but this isn't that necessary. >> >> The hope is that people will migrate towards using AppConfig in their >> settings, and then we can reconsider. Third party apps who wish to do a lot >> of logic there may wish to require it. >> >> Personally I'm torn, as I can see the benefits of a convention. But >> equally I don't think there's a huge amount of point making a big effort to >> rewrite Django's import handling in order to add more magic back in. >> >> See my comments to Aymeric. I'm not blind to the concerns you've raised > here - there certainly valid ones, and I appreciate (and sympathise with) > the intent. I'm just stuck in a bind where there's a new feature that will > fix my problem much better than the existing alternatives -- I just can't > use it. > > I'm completely open to other approaches that don't require speculative > imports. Aymeric's suggestion of an attribute in the root module sounds > like a good option to me -- it only requires an attribute access in a > module that you're already importing, and you use that string to provide > the value that we'd like to tell the end user to put in their > INSTALLED_APPS. However, it sounds like Aymeric wasn't as keen on this > approach. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJxq84_MPKw_zywaeaQ-4aXDYaTVJxfRtm%2B-2GEXrrn7D7VwJQ%40mail.gmail.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1H9i1t7iGCQCHSV-B4GCgMac2CWDYfLxQoo8Zw%2BD_mXvQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
