id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
22920	AppConfig.create swallows informative exceptions during import time	Ben Davis	Aymeric Augustin	"If you have an `INSTALLED_APPS` entry that doesn't use an AppConfig, and that module has more than one level, eg ""myproject.myapp"", `AppConfig.create` will swallow any exceptions that occur during the import of that module, losing valuable traceback information. The `create` method makes some incorrect assumptions about the entry. Mainly it assumes that if the entry has more than one part and the import fails, that it must be an `AppConfig` class (which is incorrect).

I've submitted a PR with a fix for this. Basically the new algorithm is as follows:

1. Split the entry into `mod_path` and `ending`. If it's a single-level module, `ending` is empty.
2. Attempt to import `mod_path` as `module`, allowing exceptions to propagate (no try/catch)
3. Check if `ending` is an attribute of `module`. 
  - If the attribute doesn't exist OR the attribute exists and is a module, import the full entry as `module` (again, allowing exceptions to propagate)
  - If the imported module does NOT a `default_app_config` attr, return with a default AppConfig instance.
  - Otherwise, import the module path from `default_app_config` entry as `module` (again, allowing exceptions to propagate), and assume the ending is a class name.
4. If `ending` ''was'' an attribute of `module` in step 3, we can assume it's an AppConfig class.
5. At this point we have a legitimate module and an object which should be a class, and can continue on to validate the AppConfig class."	Bug	closed	Core (Other)	dev	Normal	fixed	AppConfig app-loading ImportError		Accepted	1	0	0	0	0	0