Thanks for bringing this topic up for discussion. > jezdez says: "As Jacob said, that's such a pain. I tried and wasn't > able to implement even part of the wanted features. The app cache > needs a thourough look. But I don't see installing apps multiple times > as a favored feature. I will happily participate in any work on this." > > Well, what are those features you wanted, explicitly?
Mostly what has been written down at http://code.djangoproject.com/wiki/InstalledAppsRevision . Using an app multiple times is pretty difficult since it requires changes in the way the models are registered. To be honest, I'm not sure what the use case is for that. Could someone give an example please? > The "apps multiple times" would be a corner case, the minimum benefits > are third-party app disambiguation and verbose names for apps in the > admin. Did you try the #3591 patch? Yes, I tried it but wasn't convinced of how it's bound to the settings. In my (indeed unfinished) try I refactored the AppCache to live in django.core.apps that would contain instances of the new django.core.apps.base.App base class, each representing an app entity. The model loading mechanism would then use the app instances to get a list of available models, instead of the global model registry Django has now. Moving the app definition out of the settings.py would also allow i18n and all the other wonderful benefits class inheritance brings. Users would be able to subclass the django.core.apps.base.App to use hooks for app-level testing, signal registration, database prefixes and verbose names. INSTALLED_APPS could then be a list of: a) a Python path to that app class or b) a path to a Python module, e.g.: INSTALLED_APPS = ( 'django.contrib.admin', 'tagging.app.TaggingApp', 'registration', ) Those items in INSTALLED_APPS that aren't paths to App subclasses would prompt the AppCache to create App instances on runtime by using the base class -- much like the admin does it now with ModelAdmin classes. Additional (and future) use cases could be inter-app dependencies and compatibility with the WSGI app standard -- although I understand that's very much debatable. Cheers, Jannis --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
