Changes between Version 2 and Version 3 of SummerOfCode2014

Timestamp:

Feb 6, 2014, 6:51:03 PM (10 years ago)

Author:

Russell Keith-Magee

Comment:

Added myself to mentor list, and added another possible project.

SummerOfCode2014

@@ -12 +12 @@
  * Tim Graham (timograham@gmail.com) - TBA
  * Marc Tamlyn (marc.tamlyn@gmail.com) - test suite improvements
+ * Russell Keith-Magee (russell@keith-magee.com) - Meta refactor, Reducing coupling
 
 == Students ==
@@ -160 +161 @@
 === Formalizing the Meta object ===
 
+* '''Complexity:''' Medium
+
 Every Django object has a `_meta` attribute that contains lots of useful introspection metadata about the object, its fields, and its relationships with other models. This `_meta` object is essential to the operation of Django itself, providing the framework for features like ModelForms, and the automatic behaviour of the Admin.
 
@@ -165 +168 @@
 
 It would be desirable to be able to formally publish a stable API spec for Meta. Many projects already rely on Meta as if it were stable API. This would involve auditing the current contents of Meta, doing some API cleanup to provide a consistent and clean API, and documenting that API. Issues of backwards compatibility need to be kept in mind -- even though Meta isn't formally covered by Django's backwards compatibility policy, it's a 'defacto' standard, so we can't just change it arbitrarily.
+
+=== Reducing coupling in Django components ===
+
+* '''Complexity:''' Hard
+
+Django is currently delivered as a single monolithic download. This is largely for historical reasons; when Django started as a project, Python's packaging infrastructure wasn't especially mature. This situation has has improved over the years, and now Python has a rich set of packaging tools. In an ideal world, it would be possible to download "Just the Django template engine", or "Just the Django ORM", or "Just the Django forms layer"; the combined Django download would really be a meta-package install of all the required parts.
+
+There are two technical problems that need to be solved in order to make this happen.
+ 
+ * Implement the packaging definitions to allow for multiple packages.
+ * Clean up dependencies between components. Despite the best of intentions, there are some interesting dependencies between modules, some of which may need to be clarified or separated.
+
+The aim of this project would be to clean up one or more of Django's internal "parts" so that it could be delivered as a standalone package. This may not be something that can be immediately delivered - for example, it may be necessary to move or rename components to enable separate packaging. In this case, the project deliverable would be to document the strategy, and provide whatever initial moves in that direction are possible.
+
+A simpler version of this project would be to enable separate packaging and distribution of Django's contrib apps.