This allows bringing back the behavior of Django < 1.7.
Also fixed the check for the app registry being ready in
AppConfig.get_model(s), which was inconsistent with the equivalent check in
Apps.get_model(s). That part is a backwards-incompatible change.
It was inconsistent with the equivalent check in Apps.get_model(s)
because I made incorrect assumptions when I wrote that code and
needlessly complicated readiness checks.
This is a backwards-incompatible change.
Moved the lookup in Field.swappable_setting to Apps, and added
an lru_cache to cache the results.
Refs #24743
Thanks Marten Kenbeek for the initial work on the patch. Thanks Aymeric
Augustin and Tim Graham for the review.
This adds a new method, Apps.lazy_model_operation(), and a helper function,
lazy_related_operation(), which together supersede add_lazy_relation() and
make lazy model operations the responsibility of the App registry. This
system no longer uses the class_prepared signal.
Set apps.ready to False when rendering multiple models. This prevents
that the cache on Model._meta is expired on all models after each time a
single model is rendered. Prevented that Apps.clear_cache() refills the
cache on Apps.get_models(), so that the wrong value cannot be cached
when cloning a StateApps.
Previously a RuntimeError was raised every time two models clashed
in the app registry. This prevented reloading a module in a REPL;
while it's not recommended to do so, we decided not to forbid this
use-case by turning the error into a warning.
Thanks @dfunckt and Sergey Pashinin for the initial patches.
Wherever possible this filesystem path is derived automatically from the app
module's ``__path__`` and ``__file__`` attributes (this avoids any
backwards-compatibility problems).
AppConfig allows specifying an app's filesystem location explicitly, which
overrides all autodetection based on ``__path__`` and ``__file__``. This
permits Django to support any type of module as an app (namespace packages,
fake modules, modules loaded by other hypothetical non-filesystem module
loaders), as long as the app is configured with an explicit filesystem path.
Thanks Aymeric for review and discussion.
Also document the conditions under which a namespace package may or may not be
a Django app, and raise a clearer error message in those cases where it may not
be.
Thanks Aymeric for review and consultation.