[Django] #27362: Omitting default_app_config in __init__.py happens to easily.
Django
--------------------------------+--------------------
Reporter: Thomas Güttler | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+--------------------
Up to now it is likely that the programmer forgets to add
"default_app_config = 'myapp.apps.AppConfig" in `__init__.py`.
It took too much time to debug why the signal handled of a reusable app
was not called on one system (INSTALLED_APPS=[... 'myapp'])
and called on another system (INSTALLED_APPS=[...,
'myapp.apps.AppConfig']).
I have no clue how to solve this at the moment.
But I hope you can understand that "pain".
What can be done to assist the programmer?
Related docs: https://docs.djangoproject.com/en/1.10/ref/applications
/#configuring-applications
--
Ticket URL: <https://code.djangoproject.com/ticket/27362>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Thomas Güttler | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Aymeric Augustin):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Yes, I can see the problem.
That's one of the reasons why I'm against `default_app_config`. It's only
there for backwards compatibility and should only be used by pluggable
apps that predate Django 1.7, need a custom app config and don't want to
ask their users to update their `INSTALLED_APPS` setting.
Unfortunately, even if `default_app_config` was removed, we'd still be
stuck with two kinds of apps: those that provide a custom AppConfig and
those that don't. This results in a mixed style in `INSTALLED_APPS`, and
then it's easy to reference an app by its package name and load it with
the base `AppConfig` class instead of its custom `MyAppConfig` class.
Like you I'm not really coming up with great ideas to improve the
situation...
--
Ticket URL: <https://code.djangoproject.com/ticket/27362#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: Thomas Güttler | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: 1.10
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* status: new => closed
* type: Uncategorized => Cleanup/optimization
* component: Uncategorized => Core (Other)
* resolution: => needsinfo
Comment:
There was #25356 in which it was suggested that `default_app_config` is
discouraged and shouldn't be in the default app template.
Closing as needsinfo absent a way to move forward with the ticket. Feel
free to reopen if anyone thinks of actionable items.
--
Ticket URL: <https://code.djangoproject.com/ticket/27362#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: Thomas Güttler | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: 1.10
Severity: Normal | Resolution: needsinfo
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Thomas Güttler):
What kind of info is needed?
--
Ticket URL: <https://code.djangoproject.com/ticket/27362#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: Thomas Güttler | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: 1.10
Severity: Normal | Resolution: needsinfo
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
A proposed solution.
--
Ticket URL: <https://code.djangoproject.com/ticket/27362#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: Thomas Güttler | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: 1.10
Severity: Normal | Resolution: needsinfo
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Aymeric Augustin):
Historically this ticket would have been kept open in the "design decision
needed" stage. We started closing tickets with no clear way forwards a
couple years ago to keep open tickets actionable.
I believe that the documentation is clear is it stands and (unfortunately)
not a good solution here because a programmer debugging such a problem is
unlikely to be perusing the documentation of apps.
Perhaps we could add a check to raise a warning if there's an AppConfig
subclass defined in an `apps` submodule -- the conventional location? That
seems quite prone to false positives...
Other arguments or ideas welcome...
--
Ticket URL: <https://code.djangoproject.com/ticket/27362#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: Thomas Güttler | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: 1.10
Severity: Normal | Resolution: needsinfo
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Thomas Güttler):
We use this test to unsure that the same error does happen again:
{{{
def test_app_config_registered(self):
for app_config in apps.get_app_configs():
if not app_config.__module__=='django.apps.config':
# This app has an own AppConfig class registered: ok
continue
apps_module_path='%s.apps' % app_config.name
try:
import_module(apps_module_path)
except ImportError:
# No module called "apps": ok
continue
raise AssertionError('%s exists, but the registry
(apps.get_app_configs()) contains the base class. Please use dotted python
path to AppConfig in INSTALLED_APPS or use default_app_config in
__init__.py' %
(apps_module_path))
}}}
I guess this can't be integrated into django.
--
Ticket URL: <https://code.djangoproject.com/ticket/27362#comment:6>