AppConfigs aren't loaded when the application is in a nested directory

[Josh Smeaton]

We had someone in IRC trying to use a custom AppConfig with an application that was installed to a subdirectory called "apps". The AppConfig wasn't being picked up, and the import_module machinery was throwing errors. I've replicated this locally too.

Application at: project/top/drill/

INSTALLED_APPS = [
    'top.drill',  # with default_app_config 
    'top.drill.apps.DrillConfig',  # without default_app_config
]

$ ./manage.py shell
Traceback (most recent call last):
  File "./manage.py", line 9, in <module>
    execute_from_command_line(sys.argv)
  File "/vagrant/venv/lib/python3.3/site-packages/django/core/management/__init__.py", line 427, in execute_from_command_line
    utility.execute()
  File "/vagrant/venv/lib/python3.3/site-packages/django/core/management/__init__.py", line 391, in execute
    django.setup()
  File "/vagrant/venv/lib/python3.3/site-packages/django/__init__.py", line 21, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/vagrant/venv/lib/python3.3/site-packages/django/apps/registry.py", line 85, in populate
    app_config = AppConfig.create(entry)
  File "/vagrant/venv/lib/python3.3/site-packages/django/apps/config.py", line 137, in create
    app_module = import_module(app_name)
  File "/vagrant/venv/lib64/python3.3/importlib/__init__.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1584, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1529, in _find_and_load_unlocked
ImportError: No module named 'drill'

Problem happens using default_app_config or by referencing the AppConfig from INSTALLED_APPS. I suspect there's a problem related to importing modules when the application isn't in the project root directory.

I think that https://code.djangoproject.com/ticket/23470 was the same problem, but it was never fully investigated.

[Josh Smeaton]

I should note that the same setup works when moving the application back to the project root directory (and updating paths to remove the "top" module part).

[Abhaya Agarwal]

The error occurs when Django tries to import the module named in AppConfig. I suspect you have only drill specified there, just like #23470. The error will go away if the name in app config is changed to top.drill.

Perhaps documentation should be updated to explicitly say that the name in app config should match what we put in INSTALLED_APPS or that it should be importable?

[Carl Meyer]

The documentation already seems pretty clear that AppConfig.name should be the full Python dotted path to the app: ​https://docs.djangoproject.com/en/1.8/ref/applications/#django.apps.AppConfig.name

Josh, can you verify what the value of the name attribute in your AppConfig class for your test was?

[Josh Smeaton]

Test project demonstrating problem

[Josh Smeaton]

Yep, sorry. It was the name attribute of the AppConfig causing the problem. Documentation is quite clear if you continue reading to the end of ​https://docs.djangoproject.com/en/1.8/ref/applications/#for-application-authors.

[Carl Meyer]

I think something like path might be clearer than name for that attribute (name evokes something human-readable), but it's too late for bikeshedding those names now!

[Aymeric Augustin]

path was already used to store the filesystem path to the package (when this concept makes sense).