Changes between Version 1 and Version 2 of AppLoadingRefactor


Ignore:
Timestamp:
06/11/12 15:37:21 (3 years ago)
Author:
mjtamlyn
Comment:

Expand on current status as of June 2012

Legend:

Unmodified
Added
Removed
Modified
  • AppLoadingRefactor

    v1 v2  
    11This is an attempt to bring together the current state and long term plans of how
    22application loading is done in Django, what it could do, and why.
     3
     4''Author: Marc Tamlyn. Hence references to "me" or "I"''
    35
    46== Application loading refactor ==
     
    101103
    102104
    103 === Implementation plan ===
     105=== Implementation plan (incomplete) ===
    104106
    105107Application class. Talk about what APIs would bee needed on that class to
     
    120122=== Current status ===
    121123
     124This concept has been around in the Django ecosystem for about 4 years now.
     125The original impetus was to allow custom `app_label` and `verbose_name`
     126attributes on an app (see #3591). The sticking point was often the difficulties of
     127installing the same app multiple times - there are a bunch of problems with this,
     128not least including dealing with `from grail.models import Spam`. Well, which
     129version of `Spam`?
     130
     131An original discussion of the ideas can be found at InstalledAppsRevision.
     132
     133It was taken on as a Google Summer of Code project in summer 2010 by Arthur
     134Koziel. Good progress was made, with a refactor of the `AppCache` and a new
     135`App` class. Some of the design decisions made are discussed here:
     136https://groups.google.com/forum/?fromgroups#!topic/django-developers/TMoght1IWHk
     137
     138The last action on this branch was in summer 2011 by Jannis. Travis Swicegood
     139and Marc Tamlyn have both expressed interest in working further with the project.
     140
    122141Preston has merged master into the existing branch with work done by Jannis and
    123142Arthur. (https://github.com/ptone/django/commit/8722bdcc17293baa8b527ae7169b9a465e728d41)
    124143
    125 We need to evaluate which of the current features are implemented, and which are
    126 not.
    127 
    128 Update tests so that everything passes again, including outside of the appcache
    129 tests.
    130 
    131 Try to work out which parts of the implementation plan are tangential to
    132 each other, and therefore could easily be worked on by other people.
     144The app cache branch has a good number of tests, but little documentation. We
     145need to start by working out what has been achieved so far and how it fits in with
     146the long term plan. The tests for the new classes work, but there are a few other
     147tests breaking as a result of them expecting certain behaviour about the `AppCache`.
     148Personally, I would like to see code removed from all of these places and the
     149`AppCache` made more powerful. These tests will need fixing before any merge
     150to trunk can be made.
Back to Top