> Thank your for taking the time to consider this project, hopefully you > will get some other feedback than just mine - I'm not sure that many > projects are worthy of *two* GSOC projects myself. > I don't know, but I think GSOC still offers a good chance to finish off the people's valuable work on app loading. And this idea has been listed on the Django GSOC-Idea page, which has a little high priority, so I think it may be a good summer project for student to complete it to a good status. Take a look at: https://code.djangoproject.com/wiki/SummerOfCode2012
> I believe that the baton was somewhat passed to tswicegood at pycon, see: > > > https://github.com/tswicegood/django/commit/241c455d9b8d03144a24f869f819efda031813ba > > I will take a good look at it. > >> 1 current app loading features >> 1) app can be reused in multiple projects >> > > not sure how this is related to app_loading, it is the case currently > You are right, while what I mean is app_loading allow settting a string in the INSTALLED_APPS, thus can allow same app to be used in different projects. > > >> 2) reused app can be found by Django in INSTALLED_APPS of settings.py, >> which is written in dotted path >> 3) each string in INSTALLED_APPS should be a full Python path to a >> Python package that contains a Django application, as created by >> django-admin.py startapp >> > > While I think this should still be true, currently there is the option for > an iterable for defining an app, there was an "APP_CLASSES" setting in the > branch transiently, but is now gone. I think it would be better to keep > INSTALLED_APPS flat and introduce a new setting for configured apps - which > could then add their flat representation to INSTALLED_APPS > You are very right, the following is a good way: settings.INSTALLED_APPS = ('django.contrib.auth', App('django.contrib.admin', name='SuperAdmin'), App('myapp', name='Wow', db_prefix='pref')) But I am still not sure I should consider this stuff in this summer proposal or project, because it has been implemented in a raw way through the work in 2010 and 2011 I think, what I do is to check if it can well do this and other good things as expected. However, if it does not perform well, I still need to enhance the code. > > 4) app names must be unique >> > > This is, as far as I can tell from my review, and unresolved limitation in > the current branch - that django.contrib.auth and mypackage.auth collide. > Seems a duplicate of your #3 below. > OK, there is still not a workaround way? > >> 2 'future' app loading features >> 1) backward compatibility: 'future' app loading mechanism should >> support current app loading features well >> > > This backwards compatibility is present currently as a set of module level > functions at the old location in the db module > Sounds good. > > >> 2) can deploy several instaces of the same application >> > > If you see the discussion here: > > > http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/5045645100f5b8ea?lnk=gst&q=app+loading#5045645100f5b8ea > > It was determined that this feature was too problematic to tackle as part > of app_loading > A good start point to check if previous work has solved this problem or not ? > > >> 3) can deploy two applications with the same name,(not have the >> requirements of unique app name) >> > > There remains some room for improvement and clarification about what an > app_name is vs app_label vs fully qualified name > Yes, it can be one part of this summer work if this proposal can be accepted. > > >> 4) convenient interface for internationalizing application names > > 5) good support to rename an application with a name that isn't >> helpful from a UI >> perspective >> > > Some of the above needs clarification. > > I do think app_loading needs some sort of new push - but I'm dubious that > a GSOC would be the way to go. > I don't know if there is a better way, but I just want to help it move forward even in one step. If time permits, work can be continued after summer. > > For your detailed plan, I would complete your items for week 1 and 2 > before writing a final proposal, not as part of your proposal. > OK, I will spend more time on the week1and week2 work before summer coding begins. At last, thank you very much to you for these good suggestions, and I think it will help me a lot to make a good proposal and maybe-good project in this summer. Best regards, nauho -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
