AppConfig.create swallows informative exceptions during import time
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:
- Split the entry into
ending. If it's a single-level module,
ending is empty.
- Attempt to import
module, allowing exceptions to propagate (no try/catch)
- Check if
ending is an attribute of
- 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.
ending was an attribute of
module in step 3, we can assume it's an AppConfig class.
- 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.
Change History (6)
|Patch needs improvement:
app-loading added; app loading removed
changed from nobody to Aymeric Augustin
Release blocker →