On Wed, Apr 7, 2010 at 10:26 PM, Jannis Leidel <jan...@leidel.info> wrote: > > Am 07.04.2010 um 13:40 schrieb Russell Keith-Magee: > >> On Mon, Apr 5, 2010 at 5:35 AM, Arthur Koziel <art...@arthurkoziel.com> >> wrote: >>> Hi, >>> I’m going to apply for GSoC with the goal of refactoring the app loading >>> [0]. I’ve been looking at Django’s current app loading implementation >>> (db.models.loading), Vinay Sajip’s patch in #3591 [1] and the notes on the >>> InstalledAppsRevision wiki page [2]. Here's what I'm planning to change. Any >>> feedback is appreciated. >>> Step 1 >>> --------- >>> Deal with the two main problems of the current app loading implementation, >>> and make it possible to: >>> - deploy several instances of the same app >>> - deploy two apps with the same name >>> The INSTALLED_APPS setting will be changed to: >>> >>> INSTALLED_APPS = InstalledApps( >>> 'django.contrib.auth', # strings will be converted to App() >> >> Strings will be converted to App()... by What? When? >> >> What happens to existing code that is using "for app in INSTALLED_APS" >> as an idiom? > > I'm worried that creating the app instances with an ``app()`` callable would > require an import and contradicts with the convention of having dotted paths > for any configurable extension.
Agreed. Starting down the path of requiring imports in the settings file isn't something I'd like to encourage. > That's why I think INSTALLED_APPS should be kept as an iterable of dotted > paths which is converted to an app registry during the start-up (which > already happens for wildcard entries like "django.contrib.*"). Each entry of > the list would be a string with one of the following values: > > - Dotted path to an app module (current default, e.g. 'django.contrib.auth'). > During the start-up an anonymous app instance would be initialized, using the > models module of the loaded app module. > > - Dotted path to an app class (e.g. 'django.contrib.auth.AuthApp'). During > the start-up a named app instance would be created, either with the models > module of the module the app class is located in, the model attribute of the > class or none (model-less app). > > - Dotted path to an app instance (e.g. 'django.contrib.admin.site'). During > the start-up an existing app instance would be handled like it has been > loaded in one of the former two cases. I like this; although I think it has some potential to cause a whole different bunch of headaches. At the moment, "for app in settings.INSTALLED_APPS" is guaranteed to give you a list of app names; identifying the difference between an app module, and app class and an app instance isn't going to be trivial from the point of view of an end developer -- since, at the end of the day, they're all just strings. Yours, Russ Magee %-) -- 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.
