Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#24801 closed Bug (invalid)

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

Reported by: Josh Smeaton Owned by: nobody
Component: Core (Other) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

appconfig_24801.tar.gz (2.3 KB ) - added by Josh Smeaton 9 years ago.
Test project demonstrating problem

Download all attachments as: .zip

Change History (8)

comment:1 by Josh Smeaton, 9 years ago

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).

comment:2 by Abhaya Agarwal, 9 years ago

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?

comment:3 by Carl Meyer, 9 years ago

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?

by Josh Smeaton, 9 years ago

Attachment: appconfig_24801.tar.gz added

Test project demonstrating problem

comment:4 by Josh Smeaton, 9 years ago

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.

comment:5 by Josh Smeaton, 9 years ago

Resolution: invalid
Status: newclosed

comment:6 by Carl Meyer, 9 years ago

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!

comment:7 by Aymeric Augustin, 9 years ago

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

Note: See TracTickets for help on using tickets.
Back to Top