After a long two-day sprint on this, hitting road-block after road-block, we've learned a whole lot. Here's where we are:

Impetus

During the state of Django talk, Adrian put up a slide showing an INSTALLED_APPS setting like this:

    INSTALLED_APPS = Apps(
       app('django.contrib.admin'),
       app('project.app', name='polls'),
    )

The idea is to allow more robustness and extensibility in the INSTALLED_APPS. We came into this thinking it would be rather simple, but after a while, that was seen to be anything but the case.

Design Goals

• Allow change of name of third-party app
• Allow change of db_prefix of third-party app
• Allow multiple instances of an app with different names, db_prefix, etc.

Initial Plan

db.models.loading becomes core.apps. db.models.loading is kept only for backwards compatibility, redirecting to core.apps. AppCache becomes InstalledApps App class added to hold name, path, db_prefix, etc. settings.INSTALLED_APPS becomes instance of InstalledApps, and converts every item to an App instance if it is a string.

settings.INSTALLED_APPS = ('django.contrib.auth',
			   App('django.contrib.admin', name='SuperAdmin'),
			   App('myapp', name='Wow', db_prefix='pref'))

After accessing settings this becomes (pseudo):

InstalledApps(App(path='django.contrib.auth', name='auth'),
              App(path='django.contrib.admin', name='SuperAdmin'),
	      App(path='myapp', name='Wow', db_prefix='pref'))

For backwards compatibility, set model._meta.app_label to specified name. Going forward, set model._meta.app to App instance, use model._meta.app.name, model._meta.app.db_prefix, etc.

Provide signal when InstalledApps is finished loading apps.

Multiple instances of an app would NOT be solvable with this, so long as we are attaching and consuming this metadata via model._meta (since model classes would still be shared by the instances). No approaches that didn't herald the return of magic were floated for this. This issue is most likely shared by any multiple-database solution that hopes to allow the same models to be used in different contexts against different databases, so that work may provide a useful solution here as well.

Issues Found During Dev

Today model._meta.app_label is implicitly forced to be the filesystem dir name above models.

Currently model._meta.app_label is heavily overloaded, acts as:

• Admin app display name (by .title())
• Admin permissions prefix
• DB table creation prefix
• Dumpdata/Loaddata fixture prefix identifier
• When explicitly set, used to associate models elsewhere in the app structure.
• RelatedObject explicit cross-app identification.
• contrib.contenttypes identification

Some of these should remain in the developer's control (model association, cross-app model id). Some of these should be in the installer's control (admin name, db table prefix). Some of these should use new db_prefix instead (table creation, fixtures?). Some of these it's not clear (contenttypes, permissions).

Keeping the interfaces of get_apps, get_models, etc is problematic as some of these just take a models module (and determine the app label by the fs dir name), or return the models module. It would be preferrable if these took and returned App instances (which would have a .module attribute), but with larger compatibility ramifications.

Initial attempt at resolving these differences was to have InstalledApps keep two app->models dicts, one by module_name (old app_label) and one by app.name (specified in settings). This lead to a separation between get_model and get_model_from_module_name, the latter used for model association etc that should remain under the original app developer's control.

Populating the by-app.name mapping is hackish, since it's not knowledge that's available to ModelBase.new for register_models. Instead, after loading each app we find models by the module_name and store matching entries in the app.name dict.

Additionally there are a number of places that use the string paths from INSTALLED_APPS:

• management, translation, templatetags/template loaders (to do further imports)
• test.client (to check if sessions are available)

These were straightforward to switch to use app.path

Unresolved

Whether this approach is overall worthwhile given that it does not address installing multiple instances of an app. Whether contenttypes, permissions, etc should use module_name or app.name or an additionally configurable value (either by app developer or installer). How much backwards incompatibility is acceptable in terms of get_apps/get_models/etc, iter(settings.INSTALLED_APPS), other third-party overloading of _meta.app_label.