Changes between Version 1 and Version 2 of AppLoadingRefactor

06/11/2012 03:37:21 PM (8 years ago)
Marc Tamlyn

Expand on current status as of June 2012


  • 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.
     4''Author: Marc Tamlyn. Hence references to "me" or "I"''
    46== Application loading refactor ==
    103 === Implementation plan ===
     105=== Implementation plan (incomplete) ===
    105107Application class. Talk about what APIs would bee needed on that class to
    120122=== Current status ===
     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`?
     131An original discussion of the ideas can be found at InstalledAppsRevision.
     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:
     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.
    122141Preston has merged master into the existing branch with work done by Jannis and
    123142Arthur. (
    125 We need to evaluate which of the current features are implemented, and which are
    126 not.
    128 Update tests so that everything passes again, including outside of the appcache
    129 tests.
    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