Changes between Version 3 and Version 4 of SummerOfCode2023
- Timestamp:
- Jan 26, 2023, 8:29:49 AM (17 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SummerOfCode2023
v3 v4 43 43 44 44 * Work on Django itself - such as the ORM, forms, etc. This is what we've traditionally accepted GSoC entries in. 45 * Work on tools to support Django - the dashboard (https://dashboard.djangoproject.com/) is a good example of an existing tool that would have fit into this category.45 * Work on tools to support Django - the issue tracker dashboard (https://dashboard.djangoproject.com/) is a good example of an existing tool that would have fit into this category. 46 46 * Work on libraries that supplement or add new features to Django to ease development - South and Django Debug Toolbar are good examples of existing projects that would have fit here. 47 47 … … 66 66 core developers can help mentor you on. 67 67 68 We're also not looking for sites or projects that are merely written in Django 69 - this GSoC is not for you to propose your new forum hosting site or amazing 70 Django-based blogging engine. 68 We're also not looking for sites or projects that are merely written in Django — this GSoC is not for you to propose your new forum hosting site or amazing Django-based blogging engine. 71 69 72 70 Note that when you contribute code, you will be expected to adhere to the same … … 76 74 [http://groups.google.com/group/django-developers django-developers] and the 77 75 [https://forum.djangoproject.com Django Forum] when your topic of interest is 78 raised. If you're not already familiar with 79 [http://docs.djangoproject.com/en/dev/internals/contributing/ Django's 80 contribution guidelines], now would be a good time to read them - even if 76 raised. If you're not already familiar with [http://docs.djangoproject.com/en/dev/internals/contributing/ Django's contribution guidelines], now would be a good time to read them - even if 81 77 you're not applying to work on Django core directly, we'll still want the same 82 78 level of contribution. … … 85 81 86 82 The best thing you can do to improve your chances to be accepted as a Django 87 GSoC student is to start contributing now. Read up on 88 [https://docs.djangoproject.com/en/dev/internals/contributing/ Django’s 89 contribution documentation] and make yourself known to the core team by your 83 GSoC student is to start contributing now. Read up on [https://docs.djangoproject.com/en/dev/internals/contributing/ Django’s contribution documentation] and make yourself known to the other contributors by your 90 84 contributions (ideally, related to the area of your proposal). That way, when 91 it comes time to evaluate student applications, you’ll be a known individual85 it comes time to evaluate student applications, you’ll be a **known individual** 92 86 and more likely to be able to get the attention you need to develop a proposal. 93 87 … … 100 94 == Communication == 101 95 102 All GSOC-related communication is handled via the [https://forum.djangoproject.com/c/internals/mentorship/10 Django Forum, in 103 the Mentoring channel]. Any proposals for GSOC should be submitted there, as 96 All GSOC-related communication is handled via the [https://forum.djangoproject.com/c/internals/mentorship/10 Django Forum, in the Mentoring channel]. Any proposals for GSOC should be submitted there, as 104 97 well as discussion on the proposed projects and any updates that students post. 105 98 … … 114 107 ideas; please feel free to submit proposals for things not on this list. 115 108 Remember, we'd much prefer that you posted a draft proposal and your rough 116 timeline / success conditions to the the [https://forum.djangoproject.com/c/internals/mentorship/10 Django Forum, in 117 the Mentoring channel] or [http://groups.google.com/group/django-developers django-developers list], 109 timeline / success conditions to the the [https://forum.djangoproject.com/c/internals/mentorship/10 Django Forum, in the Mentoring channel] or [http://groups.google.com/group/django-developers django-developers list], 118 110 even if it's already on the list below; it will help you get feedback on 119 111 choosing the right part of a problem, as well as helping to see if there is any … … 128 120 to know what your goals are, and how you plan to accomplish them. 129 121 122 The project ideas below list key skill, but all assume a knowledge of Python, and familiarity with Django itself. 123 130 124 In no particular order: 131 125 132 126 == Database Connection Pool == 133 127 134 Difficulty: Hard 135 Size: 350hrs 136 Potential Mentors: "Florian Apolloner", "Carlton Gibson" 137 138 Django's persistent database connections do not function correctly under ASGI, for asynchronous code. As such we need a connection pool solution. 139 140 There are per-database solutions out there, e.g. PG Bouncer for PostgreSQL. Can we wrap those, or provide our own implementation if needed? 141 142 A proposal here will show awareness of the prior art, and the difficulties involved. (Background reading: https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md and https://www.psycopg.org/articles/2021/01/17/pool-design/) 128 || Difficulty || Hard 129 || Size. || 350hrs 130 || Potential Mentors || Florian Apolloner, Carlton Gibson 131 || Key Skills || Databases & ORM 132 133 Django's persistent database connections [https://code.djangoproject.com/ticket/33497 do not function correctly under ASGI], for asynchronous code. As such we need a connection pool solution. 134 135 There are per-database solutions out there, e.g. PG Bouncer for PostgreSQL, and psycopg — our PostgreSQL adapter provides [https://www.psycopg.org/psycopg3/docs/api/pool.html#psycopg-pool-connection-pool-implementations connection pooling]. Can we wrap those, or provide our own implementation if needed? There are other ORMs implementing similar, e.g. [http://docs.peewee-orm.com/en/latest/peewee/database.html?highlight=pool#connection-pooling the Peewee ORM's connection pooling]. What lessons can we learn there? 136 137 A proposal here will show awareness of the prior art, and the difficulties involved. (Some background reading: https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md and https://www.psycopg.org/articles/2021/01/17/pool-design/) 138 139 Expected outcome would be a series of PRs, or iteration on a single PR, leading towards a connection pool implementation. 140 141 The first stage would be a Proof-of-concept and high-level API design. Django's ORM supports multiple backends, so what would the exposed API look like. Can we then map that for each database. 142 143 Then documenting the API, and highlighting any gotchas to be aware of in adoption. 144 145 Final phase is ensure test coverage, and robustness of the implementation. There are always issues that come up with one backend or another that were not anticipated, so it's important to make good time getting to this point. 143 146 144 147 145 148 == Auto-importing shell == 146 149 147 Difficulty: Medium 148 Size: 175hrs 149 Potential Mentors: "Adam Johnson" 150 || Difficulty || Medium 151 || Size || 175hrs 152 || Potential Mentors || Adam Johnson 153 || Key Skills || Management commands 150 154 151 155 One of the most popular features of django-extensions is `shell_plus`, which is like `shell` but auto-imports your models for you. Adding this behaviour to core would be a great addition. … … 153 157 A proposal should consider ways to define extra things to import, perhaps a documented path of subclassing the management command and overriding a method. 154 158 159 Expected outcome would be a PR adding this to Django. 160 155 161 156 162 == Security: Bring CORS and CSP into core == 157 163 158 Difficulty: Medium 159 Size: 350hrs 160 Potential Mentors: "Adam Johnson", "James Bennett" 161 162 There are third-party apps providing support for Cross-Origin Resource Sharing (CORS) `django-cors-headers` and Content Security Policy (CSP) `django-csp `, but it would be good to have support built-in to core. 164 || Difficulty || Medium 165 || Size || 350hrs 166 || Potential Mentors || Adam Johnson, James Bennett 167 || Key Skills || HTTP request-response cycle, middleware, decorators 168 169 There are third-party apps providing support for [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS Cross-Origin Resource Sharing (CORS)] `django-cors-headers` and [https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP Content Security Policy (CSP)] `django-csp`, but it would be good to have support built-in to core. 163 170 164 171 Following the design of the CSRF/clickjacking protection, having safe defaults, and allowing straightforward per-path customisation, via e.g. decorators, would improve the security of all Django projects. 165 172 173 Outcome would be a pair of PRs adding these into Django. 174 166 175 == Migrations == 167 176 … … 170 179 For both projects: 171 180 172 Difficulty: Hard. 173 Size: 350hrs 174 Potential Mentors: "Shai Berger" 181 || Difficulty || Hard. 182 || Size || 350hrs 183 || Potential Mentors || Shai Berger, Mariusz Felisiak 184 || Key Skills || Migrations Framework 175 185 176 186 === Moving models between apps === 177 178 Support moving models between apps. This is a long-standing problem, esp. in 179 enterprise-y or just long-running projects. It's not simple and requires custom 180 migration operations to perform. 181 182 It has been discussed previously: https://forum.djangoproject.com/t/why-do-we-need-apps/827/20 187 188 Support moving models between apps. In long-running projects you often end up needing to move a model between Django apps. It's not simple, and requires custom 189 migration operations to perform. 190 191 The Django [https://docs.djangoproject.com/en/4.1/howto/writing-migrations/#migrating-data-between-third-party-apps docs have some information on this] but there's a long-standing [https://code.djangoproject.com/ticket/24686 ticket to have the migration operations auto-generated]. 192 193 Expected outcome would be a PR adding and documenting a migration operation to move a model between apps. 194 195 As a part of this, better documenting the powerful [https://docs.djangoproject.com/en/4.1/ref/migration-operations/#django.db.migrations.operations.SeparateDatabaseAndState SeparateDatabaseAndState operation] would be a benefit. (An initial waypoint may be to improve the documented advice on moving a model to use `SeparateDatabaseAndState`].) 196 183 197 184 198 === Audo-detection of custom migration operations === … … 186 200 Allow auto-detection of custom migration operations. 187 201 188 The auto-detector has its change-detection mostly hard-coded: 189 https://github.com/django/django/blob/main/django/db/migrations/autodetector.py#L104 202 The auto-detector has its change-detection mostly hard-coded: [https://github.com/django/django/blob/main/django/db/migrations/autodetector.py#L104 autodetector.py#L104] 190 203 191 204 It doesn't seem easy (or even possible with the current approach) to 192 allow third-party code to intervene. 193 194 A proposal here would need to demonstrate a plan for a route forward. 195 196 Note: These two projects are quite independent. Auto-detection of the fact that 205 allow third-party code to intervene. The list of handlers to generated the individual operations would need to be data-driven, so that custom steps could be added. 206 207 Expected outcome here would be a PR allowing auto-detection of custom migration operations. 208 209 210 **Note**: These two projects are quite independent. Auto-detection of the fact that 197 211 a model has moved between apps is not required, supporting such moves with 198 212 flags to makemigrations or even a dedicated management-command would be … … 200 214 201 215 202 - [SummerOfCode2022 (Edit) – Django](https://code.djangoproject.com/wiki/SummerOfCode2022?action=edit)203 - [WikiFormatting – Django](https://code.djangoproject.com/wiki/WikiFormatting)204 205 206 216 207 217 == Improve the Database Cache Backend == 208 218 209 Difficulty: Medium. 210 Size: 350hrs 211 Potential Mentors: "Adam Johnson" 219 || Difficulty || Medium. 220 || Size || 350hrs 221 || Potential Mentors|| Adam Johnson 222 || Key Skills || Cache Framework 212 223 213 224 Setting up a shared cache backend is nearly always required, as many … … 219 230 Django-Mysql has had a much better DB cache backend implementation since 2015: https://adamj.eu/tech/2015/05/17/building-a-better-databasecache-for-django-on-mysql/ . This has never been adapted for the other supported databases but it should be fairly straightforward, mostly some translation of SQL to different dialects. 220 231 232 Expected outcome would be a PR improvement database cache backend. 233 221 234 As a stretch goal, it would also be nice to hook the database cache tables into 222 235 migrations somehow rather than the current hacky duck typing approach: … … 230 243 For all three projects: 231 244 232 Difficulty: Hard. 233 Size: 175hrs 234 Potential Mentors: "Adam Johnson" 245 || Difficulty || Hard. 246 || Size || 175hrs 247 || Potential Mentors || Adam Johnson 248 || Key Skills || Python typing and Django-stubs 235 249 236 250 === Strict-mode support for django-stubs === … … 238 252 The django-stubs implementation does not currently pass Mypy’s strict mode. 239 253 240 Making this compliant would enable users to always use strict mode with them, improving type safety. 254 Making this compliant would enable users to always use strict mode with them, improving type safety. Expected outcome would be a PR doing that. 241 255 242 256 === Merging django-types back into django-stubs === … … 273 287 == Configurable Content Type Parsing == 274 288 275 Difficulty: Medium. 276 Size: 350hrs 277 Potential Mentors: "Carlton Gibson" 289 || Difficulty || Medium. 290 || Size || 350hrs 291 || Potential Mentors || Carlton Gibson 292 || Key Skills || HTTP request-response cycle 278 293 279 294 For Django 5.0 we're looking to modernize the `HTTPRequest` object, adding a content-type aware `request.data` property. This will parse `request.body` according to the content type. … … 284 299 - Parsers should implement a `can_handle(content_type) -> Bool` method. The first parser returning True will be selected to parse the `request.body`. 285 300 301 Expected outcome is a PR allowing configurable content type parsing. 286 302 287 303 == Window expressions improvements == 288 304 289 Add support for filtering against window expressions (see #28333), for `EXCLUDE` and currently not covered `RowRange()` cases (see #29850). 290 291 Hard project. 350hr project 292 293 Would require knowledge of the Django ORM, and the supported databases. 294 295 Expected outcome would be a PR (or a number of them) on the ORM. 296 297 Possible mentor: ''Mariusz Felisiak''. 298 299 305 || Difficulty || Hard. 306 || Size || 350hrs 307 || Potential Mentors || Mariusz Felisiak, Simon Charette 308 || Key Skills || ORM & SQL. 309 310 There are a group of possible improvements to the Django ORM's handling of window expressions. In particular to add support for filtering against window expressions (see #28333), and for `EXCLUDE` and currently not covered `RowRange()` cases (see #29850). 311 312 Expected outcome would be a PR on the ORM adding these features. 300 313 301 314 == Database-level Cascades == 302 315 303 Difficulty: Medium 304 Size: 350hr 305 Possible mentors: ''Mariusz Felisiak''. 316 || Difficulty || Medium 317 || Size || 350hr 318 || Possible mentors || Mariusz Felisiak, Simon Charette 319 || Key Skills || ORM 306 320 307 321 There's an old ticket to [https://code.djangoproject.com/ticket/21961 Add support for database-level cascading options]. … … 328 342 == Add Async Support to Django Debug Toolbar == 329 343 330 Difficulty: Medium. 331 Size: 350hr 332 Possible mentors: ''Tim Schilling''/''Carlton Gibson''. 344 || Difficulty || Medium. 345 || Size || 350hr 346 || Possible mentors || Tim Schilling, Carlton Gibson 347 || Key Skills || asyncio, ASGI & Channels, and django-debug-toolbar 333 348 334 349 Django Debug Toolbar (DDT) is one of the key packages in the Django ecosystem. … … 344 359 345 360 Expected outcome would be a PR (or multiple PRs) moving the toolbar towards full compatibility with Django channels and async logic. 346 347 361 348 362 … … 362 376 363 377 Possible mentors: ''Carlton Gibson'', ''Mariusz Felisiak''. 378 379 We're open to all good ideas!