Enhanced proposal:
*Proposal For “Finishing off the App Refactor”* * * * * *Abstract* --------------- Django currently assumes that an application will only ever be loaded once, and that the name of that application will be determined solely by the package name holding the models.py. A gread idea has been proposed as a GSOC idea in 2010[1] and continued in 2011[2], which will improve the old app loading mechism a lot, e.g. deploy several instances of the same application, deploy two applications with the same name, supportconvenient interface for internationalizing application names, etc. However, the [2]branch is not well prepared for being merged to the master branch, and work been made in 2010 and 2011 towards these feathers has made some big changes to current codebase, see[3]. So it's very necessary to check the changes and make sure whether these work can be merged and everything runs smoothly or not after merged. *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> reused app can be found by Django in INSTALLED_APPS of settings.py, which is written in dotted path 2> 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 3> app names must be unique 2 'future' app loading features 1> backward compatibility: 'future' app loading mechanism should support current app loading features well 2> can deploy several instaces of the same application 3> can deploy two applications with the same name,(not have the requirements of unique app 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 While,how to check these above, I think the best tool we can use is unit-test. First, we should check if all the funtions(get_apps, get_app,get_models, etc.) still work after these changes, thus the test cases towards these funtions should be run again to see if all is ok. Second, good use cases should be establised to check if it still supports current features well; we can borrow these use cases from previous work I think. Third, also construct good use cases be used to check if will-be-added features work well after merged, we can reuse the tests new app-loading has offered. But to the unittest point of view, we should pay more attention on the files which has been modified. Specifically, except for the unittest files, in [3], 6 files are added, 20 files are modifiled. Thus one part important work is to check if file changes does make bad or unexpected consequenses or not. Towards unittest files, 21 files are added, 1 file is removed, 6 files are modified, thus we also should check after these changes, whether tests still cover old app loading unit test or not, what's more, cover new features has been implemented in 2010 and 2011 well or not. The best place to start is the pull request: https://github.com/django/django/pull/129 This branch should do the following things in three aspects: a) Introduce the concept of an App object to represent each b) Keep the concept of an `app_label` as just the last part of an app's module name (example: django.contrib.auth has an app_label of auth). c) Be entirely backwards compatible The majority of the above work is already done. Two biggest hurdles should be considered to get the code merged in are: a) Getting the main test suite running again. The tests break spectacularly with the new code. Some of the failures are tests using internal APIs that changed, other are valid public APIs that haven't been ported yet. Ideally this merge should be able to take place without a single test having to be changed. b) Buy-in from all of the core-devs that this is a needed and/or good change. According to the above considerations, the detailed plan is as follows: *Detailed Plan:* ------------------------ *Week 1*: Try to merge and check if old test cases can all be run successfully, and make some necessary improvement work *Week 2-3*: Establish good use cases to check if old app loading features are all not been destroyed, meanwhile do necessary modification work *Week 4*: Check all new test cases can be run sucessfully or not, and make some necessary work to help pass all tests *Week 5-6*: 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 necessary coding work *Week 7*: Check if App object perform well or not and do necessary improvement work *Week 8*: Check if the concept of ‘app_label’ perform well not (vs. ‘app_name’) and do necessary improvement work *Week 9*: Make sure if the branch is entirely backwards compatible or not *Week 10 : *Buy-in from all of the core-devs if needed *Week 11*: Begin to create patches and create/write the documention *Week 12-Week 13*: 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 an undergraduate 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: [email protected] 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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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.
