Changes between Version 1 and Version 2 of SummerOfCode2018


Ignore:
Timestamp:
02/12/18 18:09:10 (5 years ago)
Author:
Tim Graham
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode2018

    v1 v2  
    22= Google's Summer of Code 2018 =
    33
    4 The application process for 2018 Google Summer of Code is coming soon, and Django applied as a mentor organization. Read [https://developers.google.com/open-source/soc/ Google's page] for more information on how the program works.
     4Django is a mentor organization for the 2018 Google Summer of Code. Read [https://developers.google.com/open-source/soc/ Google's page] for more information on how the program works.
    55
    66Django's GSoC program is being coordinated by Tim Graham.
     
    114114 * Similar queries for 3rd-party backends should be added here
    115115
    116 === SQLAlchemy / NoSQL integration ===
    117 * '''Complexity:''' Medium
    118 
    119 With the success of the 2014 GSoC project to formalise Meta, we're now in a position to use that interface to do interesting things.
    120 
    121 A common request over the entire life of Django has been to use Django's forms (and in particular, Django's Admin) with data stores that aren't Django's ORM. SQLAlchemy is a popular choice for those using SQL databases; a number of NoSQL data stores have also been popular at various times.
    122 
    123 The aim of this project would be to take a set of models defined in a non-Django data store, and define the mechanisms necessary to expose those models in Django's contrib.admin interface. Daniel (last year's GSOC student) proved this was possible by providing a proof-of-concept interface to Gmail inside contrib.admin.
    124 
    125 There will be two parts to this project:
    126 1. Developing a Django-Meta compliant interface for your non-Django data store of choice.
    127 2. Fixes and improvements to Django itself as necessary to support (1)
    128 
    129 The code produced under part (1) would be a standalone repository and project, *not* a candidate for inclusion into Django itself. Django won't be gaining official SQLAlchemy support - but we will be able to point at a viable proof of concept.
    130 
    131 This project could be taken up by several GSoC students, with each student developing a backend for a different data store. If more than one student is accepted for this project, they'd be expected to coordinate efforts on any bug fixing and/or improvements required in Django itself.
    132 
    133 === Template engine optimisation ===
    134 * '''Complexity:''' Medium
    135 
    136 Django's Template Language is not known for its speed, but to date little work has been published on properly profiling its internals.  Many feel there is a lot of redundant work being done in the name of surety. The aim of this project would be to profile the engine and find ways to optimise the render process.
    137 
    138 This would best be achieved by constructing a suite of rendering benchmark tests so any chances can be evaluated meaningfully for their trade offs.
    139 
    140116=== Formset improvements ===
    141117* '''Complexity:''' Low
     
    150126
    151127While it is *possible* to work around this problem, it *should* be a well documented, easy to use capability.
    152 
    153 === Improved autoreloader (#27685) ===
    154 * '''Complexity:''' Medium
    155 
    156 Django's development server includes an auto-reloader. Its design is quite old. It keeps a list of imported Python files (as well as .mo files, there's a hardcoded special case), checks every second the mtime of these files, and triggers a reload if a file was updated. This cannot be good for battery life.
    157 
    158 A more efficient implementation based on inotify is available on Linux. An implementation based on kqueue was developed at some point but quickly removed because of kqueue limitations (#21621).
    159 
    160 Several open-source projects provide modern and robust building blocks for building the autoreload feature. The most mature in general is probably watchman. The most mature Python library is probably watchdog. However their APIs are quite low level and there's no trivial way to integrate them with Django's development server.
    161 
    162 The first goal of this project is to figure out and implement this integration. This means rebuilding the development server's autoreloading feature, perhaps with a slightly different behavior and hopefully with better performance, while preserving the main APIs (`runserver`, `runserver --no-reload`).
    163 
    164 It would make sense to switch from watching all imported Python files to watching the current directory. Modifying non-Python files whose content is somehow cached in the Python process happens and is regularly reported as a bug, while modifying files in `$VIRTUAL_ENV/lib/pythonX.Y/site-packages` is an uncommon case.
    165 
    166 It will be a good opportunity to fix various bugs of the autoreloader such as the inability to detect the addition of a file, typically an `admin.py`.
    167 
    168 The second goal is to improve configurability of the autoreloader, perhaps by exposing the underlying library's configuration knobs. This will allow people to customize the behavior according to their needs, for example if they want to go back to the previous behavior and watch `$VIRTUAL_ENV`.
Back to Top