On Sun, Jan 19, 2014 at 9:52 PM, Marc Tamlyn <marc.tam...@gmail.com> wrote:
> 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. > The other option (which was option 1, and seems to have been overlooked) was to not do anything implicit, and make it a hard upgrade path using the checks framework itself. We can have compatibility checks that explicitly look for the contrib app strings in INSTALLED_APPS, and raise an error to the effect that "your app isn't being fully validated". Core compatibility checks aren't tied to apps embedded in the system, so they always run, so you wouldn't be able to do a syncdb/migrate or runserver without hitting an error that has hint telling you want you need to do. The migration itself is simple -- modify three lines in your INSTALLED_APPS, and you never see it again. It's just a question of whether we'd prefer a hands-off migration using an implicit technique, or a hands-on migration pointed to by the checks framework. > 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... ;) > Oh, that mystical land of Django 2.0, where the sun shines shiner … :-) Russ %-) -- 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_9Gj8hHJxdjESFig7zMkL5p6xx2iHAyp%3Dsz16Xu%3DB%3DvA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
