#25246 (Python 3 error in runserver when a directory is missing init.py) – Django (original) (raw)

#25246 closed Bug (fixed)

Using Python 3.4.2
One app directory is missing a number of files, including init.py
This results in an error when trying to run any manage.py command.
It seems odd that the app directory is showing up multiple times in the path, and that duplication seems to cause issues for Django.

Here is an example traceback:

(testenv)~/Development/testenv-dev/testenv$ python manage.py runserver Traceback (most recent call last): File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-packages/django/apps/config.py", line 100, in create entry = module.default_app_config AttributeError: 'module' object has no attribute 'default_app_config'

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "manage.py", line 10, in execute_from_command_line(sys.argv) File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-packages/django/core/management/init.py", line 385, in execute_from_command_line utility.execute() File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-packages/django/core/management/init.py", line 354, in execute django.setup() File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-packages/django/init.py", line 21, in setup apps.populate(settings.INSTALLED_APPS) File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-packages/django/apps/registry.py", line 85, in populate app_config = AppConfig.create(entry) File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-packages/django/apps/config.py", line 103, in create return cls(entry, module) File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-packages/django/apps/config.py", line 41, in init self.path = self._path_from_module(app_module) File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-packages/django/apps/config.py", line 70, in _path_from_module "with a 'path' class attribute." % (module, paths)) django.core.exceptions.ImproperlyConfigured: The app module <module 'emptyapp' (namespace)> has multiple filesystem locations (['/Users/jessamyn/Development/testenv-dev/testenv/emptyapp', '/Users/jessamyn/Development/testenv-dev/testenv/emptyapp', '/Users/jessamyn/Development/testenv-dev/testenv/emptyapp']); you must configure this app with an AppConfig subclass with a 'path' class attribute.

Change History(26)

comment:1 by Carl Meyer, 10 years ago

comment:2 by Carl Meyer, 10 years ago

I don't know how or why a Python 3 namespace package would end up with a __path__ containing the same directory multiple times (seems like a bug in Python, if someone is able to track down the cause), but regardless Django may as well be robust against it. We should just de-dupe __path__, probably by converting to a set, in AppConfig._path_from_module.

comment:3 by Caio Ariede, 10 years ago

comment:7 by Jessamyn Smith, 10 years ago

$ python --version
Python 3.4.2
$ python -c 'import no_init; print(no_init.path)'
_NamespacePath(['/Users/jessamyn/Development/django_error_py3/django_error_py3/no_init', '/Users/jessamyn/Development/django_error_py3/django_error_py3/no_init'])

follow-up: 9 comment:8 by Carl Meyer, 10 years ago

@caioariede I don't think we need or want an end-to-end test for this that tries to recreate the actual Python bug using a real package (it seems it's platform-specific). It would be sufficient to just add a unit test using a fake module object with a __path__ attribute containing dupes, and add the de-duping logic in _path_from_module as mentioned above, and reference the Python bug url in a comment.

comment:10 by Tim Graham, 10 years ago

If it's fixed in 3.4.3, then I suggest to close as "won't fix" as we only officially support the latest micro release of each Python series.

comment:11 by Carl Meyer, 10 years ago

Yes, I agree with Tim -- if it's fixed in 3.4.3 then we don't need to do anything.

comment:12 by Caio Ariede, 10 years ago

follow-up: 14 comment:13 by Tim Graham, 10 years ago

Jessamyn, it looks like you are on Mac. How did you install Python on your machine? I also haven't been able to reproduce the problem on Python 3.4.0 and Ubuntu 14.04. Can you test the proposed patch?

comment:15 by Jessamyn Smith, 10 years ago

I can confirm that the proposed patch fixes the issue.

follow-up: 17 comment:16 by Tim Graham, 10 years ago

Are you saying that the issue is fixed on Python 3.4.3 or that you didn't have a chance to test there?

follow-up: 20 comment:19 by Tim Graham, 10 years ago

Jessamyn, it'd be great if you could provide a test case for the ​Python bug or at least nail down the reason why you can reproduce the problem but no one else who has tried can. I'm a bit reluctant to commit the patch until we figure that out.

comment:21 by Caio Ariede, 10 years ago

Yes, it runs fine for me. Using either 3.4.2 and 3.4.3 on OSX.

comment:22 by Carl Meyer, 10 years ago

Personally I think we should just commit the patch. It's harmless, correct, improves robustness, and it has zero downside.

follow-up: 24 comment:23 by Tim Graham, 10 years ago

I'm not entirely opposed, but I think it would nice not to commit a patch that references a Python bug which is closed as "cannot reproduce" which seems to be where that bug is headed unless it gets some help. Of course, if we cannot understand the issue any better, we can just remove the ticket reference in our patch.

comment:25 by Tim Graham, 10 years ago

All right, I guess we just merge the patch and move on to more important things.

comment:26 by Tim Graham <timograham@…>, 10 years ago

Note: See TracTickets for help on using tickets.