Andrew,
Yes, that explains a lot. I'd recommend including this explanation
in one of the articles of your current series.
BTW, one other thing to keep in mind is that we 1.4 users don't
know what an apps.py file is, so we don't appreciate not having
to create one, since we never did before.
Thanks again!
--Fred
------------------------------------------------------------------------
Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
------------------------------------------------------------------------
On 10/9/14 10:09 PM, Andrew Pinkham wrote:
Hi Fred,
Thanks again for the positive feedback!
I'm sorry I lost you at the App Registry section. I'm afraid I can't recommend
an article to help with the topic, either. Given your questions, I can see I
missed the mark. Let me give it another go (warning: this is neither
technically reviewed nor copy edited).
Django uses the `INSTALLED_APPS` setting to find all of the apps in a project,
and to build a list of apps to run and use, called an app registry. The way
Django builds the app registry has changed radically from Django 1.6 to Django
1.7.
Django 1.6 (and before, but I admit I don't know how far back) used the
`AppCache` class to maintain a list of these apps. The system was problematic
because each `AppCache` instance shared state - any change to one `AppCache`
object lead to a change in all `AppCache` objects. Because of migrations (and
the need for historical/frozen models), the `AppCache` had to change in Django
1.7.
Django 1.7 now provides an `Apps` class to be the app registry. Each instance
is separate from others, allowing the migration system to build historical apps
and models. You can fetch the `Apps` object (not class!) for your own project
with:
from django.apps import apps as django_apps
Referred to as the master registry (the app registry for your project as it
runs), `django_apps` is an instance of `Apps`, which contains a list of
`AppConfig` objects.
Starting in Django 1.7 all apps now have an `AppConfig` object attached to
them. These are built automatically by Django, meaning many developers will be
able to get away without ever creating an `/app_name/apps.py` file for their
projects. The ability to override `AppConfig`, however, is quite useful. It
allows for the implementation of a `ready()` method (seen in the admin
`AppConfig` subclass) as well as the ability to explicitly set the app label,
allowing developers to easily rectify namespace conflicts.
Note that we avoid a namespace error thanks to `as django_apps` with
`AppConfig`. I recommend you do this even if there is no namespace error.
from django.apps import apps as django_apps
from . import apps
To deal with this list of `AppConfig` objects (and the models within), all
`Apps` instances sport a brand new API. We saw it throughout Part II and Part
III of the article, using it to help us with data migrations and to build our
checks.
The only trick with `Apps` is that it must be fully built and configured before
Django can take certain actions, including loading the custom user model, or
using parts of the translation system. I touched a little bit on it in Part
III, but plan to expand on it in Part IV.
The bottom line is that the app registry works mostly in the background by
building a master registry and performing many of its key functions without
developers ever knowing (just as many developers never knew about Django 1.6's
`AppCache`). However, understanding the system even a little allows for the
developer to better edit migrations and create checks, and I suspect that
interacting with apps via this API will become commonplace.
Fred: Is the above helpful? Feel free to ask more questions.
On Oct 9, 2014, at 4:53 PM, Fred Stluka <f...@bristle.com> wrote:
Otherwise, can you suggest where I can find an article similar to
yours that gets me from 1.4 to 1.5 and on to 1.6 before I use
yours to get me from 1.6 to 1.7?
No, but I hope the process I lay out in Part IV will help you indirectly.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/5437445F.6000500%40bristle.com.
For more options, visit https://groups.google.com/d/optout.
