Hey there,
the GSOC is over and I wanted to give you all a final status report.
The AppCache was refactored and now creates app instances instead of just
loading models. An app is either an instance of django.core.apps.App or a
custom class. This depends on the entry in the INSTALLED_APPS setting. Here's
an example:
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.sites',
'myproject.poll.MyPollApp',
)
With this setting, three instances will be created. Two instances of the
django.core.apps.App class and one MyPollApp instance. The MyPollApp class
could look like this:
from django.core.apps import App
from django.utils.translation import ugettext as _
class MyPollApp(App):
def __init__(self, name):
super(MyPollApp, self).__init__(name)
self.verbose_name = _('Poll')
self.db_prefix = 'foo'
The first thing to note is the verbose_name attribute, which allows for a more
descriptive name of the app. Currently the app name is the app_label, so "auth"
would be used for "django.contrib.auth". However, something like
"Authentication" would fit better from a UI perspective. The name can be passed
to the ugettext function and translated in the projects .po file on the next
run of makemessages. I modified the admin to use the verbose_name instead of
the app_label.
The db_prefix attribute allows the app to specify the prefix used when the
tables are created in the database. If the above app would have a "Poll" model,
it would be created as "foo_poll" instead of "poll_poll".
There many more attributes than can be implemented like a fixture prefix or
admin permission prefix. The models app label is currently used for far too
many things.
One thing I noticed was that a lot of code in Django itself or 3rd party apps
iterates over the installed apps and imports them. This won't work anymore as
an app can now also be a path to a class, so the import will raise an exception.
The ideal solution would be to change the code to iterate over the app
instances instead of the INSTALLED_APPS setting, but this might be a little bit
too much to ask. So, there's now an "installed_apps" attribute on the AppCache
that is a normalized version of the settings.INSTALLED_APPS variable (with
classnames removed). This makes the migration easier as this code:
for app in settings.INSTALLED_APPS:
import_module(app)
simply needs to be changed to this:
for app in cache.installed_apps:
import_module(app)
Applications with the same app label still cannot be created. The problem is
backwards compatibility, as the methods of the AppCache (get_model/get_app
etc.) all take the app_label as an argument. If, for example, there would be
two "auth" app instances (e.g. django.contrib.auth
and myproject.auth) calling get_model('auth', ...) the function must still
return the first one. I don't see migration path from app label to full path
without breaking bc.
Nevertheless, things have improved a little here. Previously, loading two apps
with the same app label would assign the models of the second app to the first
app, leaving the user with one auth app that mixed together the models from
both apps. That won't happen anymore. Now there will be only one auth app, and
the second will not be loaded. Hopefully this will clear up some confusion.
Overall, I'm happy with the result. Working on this project was a great
experience for me. I plan to continue my work on this branch after gsoc. Jannis
Leidel was a fantastic mentor, always available and really helpful.
I have the next 2 weeks filled up with exams but I'll be in Portland for
DjangoCon in early September. I'm always open to feedback and planning on
attending the sprints to do some further work. So until then...
Regards,
Arthur
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
