I don't have much to say, as Alex pretty much covered it; but that's the list:
* Assume an app1 which requires another app2 (and has some ForeignKeys to it). Currently that's easy; just import the model and ForeignKey it. How would those imports look like in your case (eg to which models would app1 link)?! [This problem could be solved by adding an app column to the models and patch all queries to just select from the current app. And yes alex's link covers that, but a reuseable app doesn't know to which app (instance) it will get linked -- yet another setting to the rescue; ah no a whole dict of settings, to specify which app instance the setting belongs to…] * What happens to login procedures etc? Eg one of the auth middlewares would stick an user object onto request.user and most of the apps won't be able to link to it, as their foreign keys point to the wrong instance of the auth app. While I am more than happy to see improvements in the app loading area (customisable names etc…), I don't like the idea of multiple instance deployments like you/alex propose (especially if that means the same set of models being installed twice/trice…; I however do like the way the admin takes). Cheers, Florian -- 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.
