Django 1.9 Apps aren't loaded yet

[Larry Martell]

I am developing a django app. I had the basic site running, but I had
not yet created any models. I created a model, and now the server
fails to start with "Apps aren't loaded yet"

traceback below. Anyone know what I am doing wrong?

Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 353, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 327, in execute
django.setup()
File "/usr/local/lib/python2.7/site-packages/django/__init__.py",
line 18, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/local/lib/python2.7/site-packages/django/apps/registry.py",
line 85, in populate
app_config = AppConfig.create(entry)
File "/usr/local/lib/python2.7/site-packages/django/apps/config.py",
line 90, in create
module = import_module(entry)
File "/usr/local/lib/python2.7/importlib/__init__.py", line 37, in
import_module
__import__(name)
File "/projects/foo/foo/app/scripts/__init__.py", line 3, in <module>
from tasks import *
File "/projects/foo/foo/app/scripts/tasks/__init__.py", line 1, in <module>
from makeworkitemlist import MakeWorkItemList
File "/projects/foo/foo/app/scripts/tasks/makeworkitemlist.py", line
2, in <module>
from foo.app.scripts.models import Reports
File "/projects/foo/foo/app/scripts/models.py", line 3, in <module>
class Reports(models.Model):
File "/usr/local/lib/python2.7/site-packages/django/db/models/base.py",
line 94, in __new__
app_config = apps.get_containing_app_config(module)
File "/usr/local/lib/python2.7/site-packages/django/apps/registry.py",
line 239, in get_containing_app_config
self.check_apps_ready()
File "/usr/local/lib/python2.7/site-packages/django/apps/registry.py",
line 124, in check_apps_ready
raise AppRegistryNotReady("Apps aren't loaded yet.")
django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.

[Michal Petrucha]

On Wed, Mar 02, 2016 at 07:05:53AM -0500, Larry Martell wrote:
> I am developing a django app. I had the basic site running, but I had
> not yet created any models. I created a model, and now the server
> fails to start with "Apps aren't loaded yet"
>
> traceback below. Anyone know what I am doing wrong?

The problem is that one of your applications (foo.app.scripts) imports
models in its top-level __init__.py. This is not supported; for an
explanation, you can read
https://docs.djangoproject.com/en/1.9/ref/applications/#how-applications-are-loaded

Good luck,

Michal

[Larry Martell]

Thanks you very much for the quick reply. Is there some workaround for
this? What version was this issued introduced in? This code works in
1.5.

[Michal Petrucha]

This is a result of making the initialization process of Django
explicit in 1.7. The correct way of fixing errors like this is to
untangle your imports, and remove anything that depends on models from
top-level __init__.py in your all your application packages. You want
to draw a boundary around all code that uses models, and make sure
that none of it is imported before django.setup() has finished.

For a quick and dirty workaround, you can always move the model import
statements into the definitions of functions that require it; that
way, the import is not executed until the function itself is called.

Good luck,

Michal

[Larry Martell]

On Wed, Mar 2, 2016 at 9:34 AM, Michal Petrucha

Thanks for the explanation. Unfortunately this app has some convoluted
code where is discovers the apps by looking for the __init_files.
Changing it will require a major reworking of a lot of code and my
client does not want to do that. So we will be downgrading to 1.6.

[marcin....@gmail.com]

The initialization process of models seems to be good step in cleaning many problems, but I don't understant why I can't import models.

The usage of the model should raise exception when it is not loaded/initialized, but not importing a model class!

This requirement breaks packages encapsulation or requires to move every models import into all functions. 

Should we stop importing models at the top of the modules, now?  

It seems like a next Django`s nightmare. 

Marcin

[James Bennett]

On Mon, Apr 25, 2016 at 8:13 AM, <marcin....@gmail.com> wrote:

The initialization process of models seems to be good step in cleaning many problems, but I don't understant why I can't import models.

The usage of the model should raise exception when it is not loaded/initialized, but not importing a model class!

Django needs to maintain a registry of all the models found in all the installed applications, and it needs each model to go into that registry once and only once (you don't want a model being registered multiple times). This requires there to be some period in time during which models are essentially "locked", so that Django has the ability to build the model registry without any other code interfering or causing duplicate copies of model classes to be floating around from stray import statements. That period occurs as Django is starting up, and until it's done you are not permitted to do anything that imports a model class.

Typically the only way to actually run into a problem with this is to be importing models inside the __init__.py file of an application, since that causes an import at the time Django is loading and inspecting the application. Avoiding imports of models at the top level of __init__.py is the solution to this (and code which needs to get a list of all applications/models should just use the API Django exposes for that rather than trying to do all the imports itself; there's a reason why Django provides introspection APIs for this).

[marcin....@gmail.com]

Hi James, good to hear you.

It is very good that app initialization is done within a special stage. I remember many problems related to imports and I'm happy that they will not occur anymore.

I understand what is done and what for. Just wondering about possibility to do some kind of late initialization.

I see that models registering is done in metaclasses, I see that app_name is used by model fields to construct related names, and so on... I've tried to move model class registration after app init, but it failed because of lot of early calls for app_name. Let's forget that for a while.

My problem is simple. When I'm developing a reusable app I'd like to expose common/main objects in the package namespace. This is done via imports from package modules. These objects often are not placed in Django modules like models.py. But they are using models via importing them into their module's namespace (typically at the top of the file). This makes chain of imports when you're trying to expose something at the package level. Exposed objects makes high-level interface to the app.

I would like to do same thing using Django 1.9+. I can set app_name explicit, I suppose, I can encapsulate model imports in methods (quite ugly when readability counts), or build proxies.

I'd glad to hear your suggestions for that.

Thanks,
Marcin

[marcin....@gmail.com]

On Monday, April 25, 2016 at 11:44:20 PM UTC+2, marcin....@gmail.com wrote:

 

Just wondering about possibility to do some kind of late initialization.

I've found Dectate library as a example of deferring configuration phase. 

I'm not talking about using it directly, but to familize with the concept.

Dectate is based on decorators, but applying the idea to metaclasses shouldn't be a problem.

The whole thing lies in registering defered intializers (model/app initializers in Django) and scan() config at the end of intitalization phase.

Marcin

[Kaleemullah Rao]

I am getting this error while i create a newapp and integrate in the setting and urls file in sample project 

C:\Users\RaoKaleemullah\Desktop\django-tutorial\sample>python manage.py runserve

r

Traceback (most recent call last):

  File "manage.py", line 10, in <module>

    execute_from_command_line(sys.argv)

  File "C:\Users\RaoKaleemullah\Anaconda2\lib\site-packages\django-1.9-py2.7.egg

\django\core\management\__init__.py", line 350, in execute_from_command_line

    utility.execute()

  File "C:\Users\RaoKaleemullah\Anaconda2\lib\site-packages\django-1.9-py2.7.egg

\django\core\management\__init__.py", line 342, in execute

    self.fetch_command(subcommand).run_from_argv(self.argv)

  File "C:\Users\RaoKaleemullah\Anaconda2\lib\site-packages\django-1.9-py2.7.egg

\django\core\management\__init__.py", line 176, in fetch_command

    commands = get_commands()

  File "C:\Users\RaoKaleemullah\Anaconda2\lib\site-packages\django-1.9-py2.7.egg

\django\utils\lru_cache.py", line 100, in wrapper

    result = user_function(*args, **kwds)

  File "C:\Users\RaoKaleemullah\Anaconda2\lib\site-packages\django-1.9-py2.7.egg

\django\core\management\__init__.py", line 71, in get_commands

    for app_config in reversed(list(apps.get_app_configs())):

  File "C:\Users\RaoKaleemullah\Anaconda2\lib\site-packages\django-1.9-py2.7.egg

\django\apps\registry.py", line 137, in get_app_configs

    self.check_apps_ready()

  File "C:\Users\RaoKaleemullah\Anaconda2\lib\site-packages\django-1.9-py2.7.egg

\django\apps\registry.py", line 124, in check_apps_ready