On Monday, March 26, 2012 7:57:02 PM UTC-7, Nauho Zen wrote: > > I have reformated my proposal content on this group, any suggestion? >
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 believe that the baton was somewhat passed to tswicegood at pycon, see: https://github.com/tswicegood/django/commit/241c455d9b8d03144a24f869f819efda031813ba See some other comments below: > > Introduction > ----------------- > > Because the purpose is to check if everything runs ok after merged, so > we should know what kind of features current app loading mechanism > supports and what kind of improvements 'future' advanced work has > made. > > 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 > 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 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. > > 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 > 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 > 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 > 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. 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. -Preston > > Detailed Plan: > Week 1: Read the source code corresponding with app loading of current > Django thoroughly, to know best what current app loading does and how > it does > Week 2: Read the source code of new app loading code, to check whether > it implement the new features interested developers proposed before > [4] > Week 3: Try to merge and check if old test cases can all be run > successfully, and make some necessary improvement work > Week 4-5: Establish good use cases to check if old app loading > features are all not been destroyed, meanwhile do necessary > modification work > Week 6: Check all new test cases can be run sucessfully or not, and > make some necessary work to help pass all tests > Week 7-8: Construct use cases to check how many new features have > already been implemented, and if there are some interesting features > that should be added, then I can do neccessary coding work > Week 9: make up current not well-done coding and tests work to make > app loading run perfectly > Week 10: Begin to create patches and create/write the documention > Week 11-12: Investigate the Django tickets host and contact with > corresponding and interested developers to know if there are some > necessary work or changes should be added , and if all is ok, try to > begin to submit the patches to Django > > > About me: > I am a student from China, and have about 3 years Python programming > skill and uses Django > for 2 years. I love this kind of activity Google has offered and am > very interested in > communicating with open source guys all over the world. Hope I can > make some contributions to Django through this wonderful activity. > > Email: zenna...@gmail.com > IRC: zennauho > > > Links: > > [1] https://code.djangoproject.com/wiki/SummerOfCode2010#Apploading > [2]https://github.com/jezdez/django/commits/app-loading > [3]https://github.com/jezdez/django/compare/master...app-loading > [4]https://code.djangoproject.com/wiki/InstalledAppsRevision > > > ------------------------------------------------------- > I will appreciate that anyone can make some suggestiones about this > proposal. We have all the same purpose to make Django better and > better. > > > Best wishes to everyone! > nauho > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/VCVw0q31IGQJ. 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.
