Hi Ben, This issue is tracked in https://code.djangoproject.com/ticket/21719. You'll see in that ticket why I failed to resolve it, and eventually gave up after wasting a few day on it.
However, you can avoid it by following two simple good practices (that were already true before app-loading): 1) Your models should be defined in an installed application and imported in its `<app>/models.py` (or `<app>/models/__init__.py`). This guarantees discoverability at startup and attribution to the correct application. Django's behavior was ill-defined before the app-loading refactoring. 2) You shouldn't import arbitrary things in your settings nor in the root package `<app>/__init__.py` of your installed applications. This guarantees that Django can import all your applications first, and then all your models. Unfortunately, for backwards-compatibility reasons, I couldn't enforce this second guideline for the admin and auth contrib apps :-( Note that it's always a good idea to keep __init__.py empty. That avoid accidentally importing unrelated things when you do a deep import. For instance, you could believe that `from django.contrib.admin.utils import flatten_fieldsets` just imports a function, but in practice it brings the entire implementation of the admin in memory, because almost everything is imported in `django/contrib/admin/__init__.py`. To sum up, I agree that the second constraint seems unnecessary, but I've been unable to relax it in practice, mostly because of the complexity of ModelBase.__new__. I'm not going to suggest you write a patch ;-) At least I hope this advice helps. -- Aymeric. On 12 juin 2014, at 00:20, Ben Davis <bendavi...@gmail.com> wrote: > In stable/1.7.x, I'm getting a lot of these warnings: > > venv/src/django/django/contrib/sites/models.py:65: RemovedInDjango19Warning: > Model class django.contrib.sites.models.Site doesn't declare an explicit > app_label and either isn't in an application in INSTALLED_APPS or else was > imported before its application was loaded. This will no longer be supported > in Django 1.9. > class Site(models.Model): > > This is usually because somewhere in one of my modules I am importing a > models.py at the top of the module, and that module is needed by something > else down the import chain. Is there any reason why this check can't be done > *after* all apps are loaded? If not, can't we just "lazy load" the model, > and then run the explicit app_label check after all apps are loaded? It's a > huge pain to have to constantly track down the import causing the warning. It > make me never want to import a models.py file anywhere other than inside a > function (which is bad). > > -- > 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/476d7e36-ab40-4d06-8123-35e899e22c6f%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/F9079450-5233-4851-ADF7-9D3B1A22BD26%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
