Four ideas from myself: 1. CORS in core
django-cors-headers’ implementation is a bit janky, for example it uses a regex to filter paths. It also lacks the key ability to set up different CORS policies per path. Both of these could be done with a decorator. I’d like to see a form of CORS support in Django that more closely follows the design of the CSRF/clickjacking protection. 2. django-stubs strict mode. The stubs do not currently pass Mypy’s strict mode. Doing so would enable users to always use strict mode with them, improving type safety. I think the other maintainers of django-stubs are also interested in this. 3. Better DatabaseCache Setting up a shared cache backend is nearly always required, as many third party packages assume the cache works like this (unlike the default locmemcache which is per process). DatabaseCache is the easiest such cache backend, not requiring any extra infra and working on shared hosts without a filesystem. But it could be better. 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/ . I’ve never got around to adapting this for postgres/sqlite but it should be fairly straightforward, mostly some translation of SQL to different dialects. It would also be nice to hook the database cache tables into migrations somehow rather than the current hacky duck typing approach ( https://github.com/django/django/blob/64b3c413da011f55469165256261f406a277e822/django/core/cache/backends/db.py#L12-L28 ). 4. Auto-importing shell One of the most popular features of django-extensions is shell_plus, which is like 'shell' but auto-imports your models for you. This behaviour would be great to have in core, with a way to define extra things to import (perhaps a documented path of subclassing the management command and overriding a method). On Wed, Nov 16, 2022 at 7:13 PM Matthew Pava <matthew.p...@iss.com> wrote: > I’m not on the technical board or of any important part of the Django > ecosystem at all, but I do have an idea. It would be nice to revamp the > “name” field in the default user model, perhaps to have one field for the > name as suggested here from the W3C: > > https://www.w3.org/International/questions/qa-personal-names > > > > I remember reading elsewhere that there were various important reasons > that prevented Django from making such a change. Perhaps it would be a good > time to review that? If there is too much controversy for having a name > field at all, perhaps eliminating it is the way to go and just have a > username field? > > > > Of course, this may go hand-in-hand with Florian’s suggestion of using > OpenID Connect. > > > > *From:* django-developers@googlegroups.com < > django-developers@googlegroups.com> *On Behalf Of *Carlton Gibson > *Sent:* Wednesday, November 16, 2022 12:58 PM > *To:* django-developers@googlegroups.com > *Subject:* Re: [Technical Board?] Project Ideas, and beginning GSoC 2023. > > > > Thanks Florian > > > > To you and all :) — casting the net wide right now is a good way forward I > think. > > We can scope down for GSoC with some ideas on the table. > > > > (Don't be shy folks. :) > > > > Kind Regards, > > Carlton > > > > On Wed, 16 Nov 2022 at 19:52, Florian Apolloner <f.apollo...@gmail.com> > wrote: > > I do have ideas but no idea about how viable they are in a GSoC context. > Nevertheless I will put write them down here, maybe we can find smaller > scopes if needed and if not, it still serves as a list of things that I'd > think to be interesting: > > > > * Probably my number one since it kinda is a blocker for me: We need a > connection pool in Django for async to work. That said connection pools are > hard to get right ( > https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md > <https://us-east-2.protection.sophos.com?d=github.com&u=aHR0cHM6Ly9naXRodWIuY29tL2JyZXR0d29vbGRyaWRnZS9IaWthcmlDUC9ibG9iL2Rldi9kb2N1bWVudHMvV2VsY29tZS1Uby1UaGUtSnVuZ2xlLm1k&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=akpaTG95QTFiaE13MFdpSDJab3RPTmRteEdGamVJOGt6eFk2Y1I4dHRYOD0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg> > and https://www.psycopg.org/articles/2021/01/17/pool-design/ > <https://us-east-2.protection.sophos.com?d=psycopg.org&u=aHR0cHM6Ly93d3cucHN5Y29wZy5vcmcvYXJ0aWNsZXMvMjAyMS8wMS8xNy9wb29sLWRlc2lnbi8=&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=QzJ2dzJBalBxWk5PaEtJaW51WkIycFh1Y0hwUmJUVndIQmw0MklwL2paYz0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg> > ). > > * Production ready webserver ( > https://groups.google.com/g/django-developers/c/q20_Cxske88 > <https://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9nL2RqYW5nby1kZXZlbG9wZXJzL2MvcTIwX0N4c2tlODg=&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=d0VlWEVBVDIrSXhWU3lYNFF5dTVCZDlVR0hBZzBVSlBlMk13d29IdTlsUT0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg>). > Maybe only focus on a smaller part first, like reading env variables / > config files. > > * Depending on how far we get with `request.data` in the meantime, maybe > put the second steps (adjustable parsers etc) in as GSoC project? > > * I haven't talked with anyone about this one yet, so it might be > completely bonkers: I think openid connect is here to stay for a while and > I'd love to see first class support in core for it. I am looking at this > from an enterprise perspective though; I do not expect a user to choose > where to login out of many options but rather provide a replacement for the > default username/password login in an enterprise environment. Most > solutions there support openid connect. Please note that I am not > suggesting to support generic OAuth2/SAML and whatnot -- there are great > 3rd party packages for that already (which also include support for openid > connect). I'd just love to be able to install arbitrary Django projects and > point them to the central authentication server. > > > > I hope this provides some ideas to get more ideas rolling :) > > > > Cheers, > > Florian > > > > > > On Tuesday, November 15, 2022 at 10:11:45 AM UTC+1 carlton...@gmail.com > wrote: > > Hi all. > > Google Summer of Code (GSoC) for 2023 has just been announced. > > https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html > <https://us-east-2.protection.sophos.com?d=googleblog.com&u=aHR0cHM6Ly9vcGVuc291cmNlLmdvb2dsZWJsb2cuY29tLzIwMjIvMTEvZ2V0LXJlYWR5LWZvci1nb29nbGUtc3VtbWVyLW9mLWNvZGUtMjAyMy5odG1s&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=ZUZSU1l5RjYxaUpvTk1EUTVYMDhtY2thTHhuOGJXay84bFlqM3QrMjZnbz0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg> > > Django has participated many times, and it's been a real boon. Recent > successes include: > > * The django-stubs mypy plugin. > * The cross-db JSON field. > * The Redis cache backend. > * Per model-class (field instance) custom lookups > * Setup of the django-asv benchmarking project. > * ... > > Application deadline for Orgs is February 7. I'll begin working on it > after the New Year. > > Main bit is an ideas list for projects. The GSoC guide has a Writing a > Good Ideas List > section. > > > Projects should take ~175 hours or ~350 hours for GSoC contributors to > complete. > > i.e. "short" or "long" projects. > https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list > <https://us-east-2.protection.sophos.com?d=google.github.io&u=aHR0cHM6Ly9nb29nbGUuZ2l0aHViLmlvL2dzb2NndWlkZXMvbWVudG9yL2RlZmluaW5nLWEtcHJvamVjdC1pZGVhcy1saXN0&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=Ync1cXVLci9zcGIvT1QweitaL0dwdHdvOEZuR3Z4dDQ3QVpaSzhndzBRRT0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg> > > I'm writing here *to solicit input on project ideas*. > > I put "Technical Board?" in the subject because we're short a list of > project > ideas for the technical direction of Django going forward, and maybe > thinking > in terms of GSoC could be a way of bootstrapping that. The "?" is because > that's not > meant to exclude other input. > > Here's last year's list for reference: > https://code.djangoproject.com/wiki/SummerOfCode2022 > <https://us-east-2.protection.sophos.com?d=djangoproject.com&u=aHR0cHM6Ly9jb2RlLmRqYW5nb3Byb2plY3QuY29tL3dpa2kvU3VtbWVyT2ZDb2RlMjAyMg==&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=WnpMU0NwZ2hlYXhvbzZKNFhsMVVGU3N3TStLWHhINEx4ZWs3TVZ0b01zOD0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg> > > - Some of those were done: benchmarking (but that could be built on) and > per-instance > field lookups. > > - Rate-limiting is a no-go I think: we couldn't come to any decent > agreement on scope, > so it's better to live as a third-party package. > > - I've tried to include folks from the wider ecosystem in previous years. > Two years ago > we had both Wagtail and django-stubs projects. Wagtail then (last year) > applied in their own right, to great success. I'd like to offer that help > again to e.g. Jazzband or other established projects, assuming > maintainers > feel they have the capacity to mentor. (It's a minor increment to my > effort > for a good return I think.) > > > No urgency but, can I ask you to put your grey cells into action? 🙂 > > > Thanks. > > Kind Regards, > > Carlton > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/2b3650c6-d340-4464-96f2-e6722a8e415an%40googlegroups.com > <https://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzLzJiMzY1MGM2LWQzNDAtNDQ2NC05NmYyLWU2NzIyYThlNDE1YW4lNDBnb29nbGVncm91cHMuY29tP3V0bV9tZWRpdW09ZW1haWwmdXRtX3NvdXJjZT1mb290ZXI=&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=aUNXTlZRSWRvYVRna24zYXRTMnp5TFdibjZrWmFrdWVGbkhYZWV0NFRSZz0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg> > . > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJwKpyRrTuPODiROeLj2wCeROdBPLaFoVXoX%3Da8Be%2BVgbJhw0w%40mail.gmail.com > <https://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzL0NBSndLcHlSclR1UE9EaVJPZUxqMndDZVJPZEJQTGFGb1ZYb1glM0RhOEJlJTJCVmdiSmh3MHclNDBtYWlsLmdtYWlsLmNvbT91dG1fbWVkaXVtPWVtYWlsJnV0bV9zb3VyY2U9Zm9vdGVy&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=MVBqeXRyMlJsZGFoTDFUUDgyVTUyTm82L3NaaEdRSXpRWFJzeDIrMFRibz0=&h=c7287be4d6014d549d93a7795f9c8969&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg> > . > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/abe04f8ef6514d41bdb7c15d6adeeaf0%40Exchange.ISS.LOCAL > <https://groups.google.com/d/msgid/django-developers/abe04f8ef6514d41bdb7c15d6adeeaf0%40Exchange.ISS.LOCAL?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0arGht_Y9JjKEsvdR9Zkb67t%3DuKThwisehVESE1gp%3Drg%40mail.gmail.com.
