Changes between Version 1 and Version 2 of AppLoadingRefactor

Timestamp:

Jun 11, 2012, 3:37:21 PM (13 years ago)

Author:

Marc Tamlyn

Comment:

Expand on current status as of June 2012

AppLoadingRefactor

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