#32915: ./manage runserver --nostatic still doesn't return a traceback
-------------------------------------+-------------------------------------
Reporter: Michael | Owner: Paul
| Schilling
Type: Bug | Status: assigned
Component: Core (Management | Version: 3.2
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Brian Helba):
I believe that #36422 (closed as a duplicate of this one) is actually
closer to the root cause, and this ticket is tracking a symptom.
The underlying problem is that when `DJANGO_SETTINGS_MODULE` fails to
import, `ManagementUtility.execute()`
[https://github.com/django/django/blob/a77be30a4346d111beaf366dcee4934734458a48/django/core/management/__init__.py#L384-L387
stashes the exception] on `self.settings_exception` and continues
silently.
There is only one code path that surfaces it to the user:
`main_help_text()`, reached by running ./manage.py with no arguments.
Every other invocation exits without mentioning that settings failed to
load, so end users have no way to diagnose the misconfiguration and remedy
it.
The user-facing problem is more significant than just the missing
traceback on runserver. Because `settings.configured` stays `False`,
`get_commands()` returns only the django.core commands and every other
command defined by an app in `INSTALLED_APPS` silently disappears. The
user runs `./manage.py actual_custom_command`, gets "Unknown command:
'actual_custom_command'", and is told nothing about why. Since we haven't
shown the user the real error with their settings, they're getting mislead
about the simplest way to fix the issue.
This ticket is focused on that same user problem: after a settings
failure, `django.contrib.staticfiles` is silently not added to
`INSTALLED_APPS`, so the `--nostatic` option disappears (since `runserver`
is never overridden). The best solution isn't to patch `--nostatic` into
the core command, it's to confront the user with the settings failure;
once they fix that, `INSTALLED_APPS` and custom commands will work again.
--
Ticket URL: <https://code.djangoproject.com/ticket/32915#comment:23>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019db58be2dc-5c1a50dc-78ee-47c2-8142-832d8b1da253-000000%40eu-central-1.amazonses.com.