Fellow Reports -- December 2019
Hi all.
Calendar Week 49 -- ending 08 December.
Released Django 3.0, 2.2.8 and 2.1.15
Triaged:
https://code.djangoproject.com/ticket/30416 -- Runserver´s reloading
mechanism should restore terminal state completely (needsinfo)
https://code.djangoproject.com/ticket/31051 -- Serialization dependency
sorting disallows circular references unneccesarily (Accepted)
https://code.djangoproject.com/ticket/31052 -- Let Django users customize
FORMAT_SETTINGS (a feature request) (wontfix)
Reviewed:
https://github.com/django/django/pull/12184 -- Fixed #31061 -- Ignored
positional args in django.urls.resolve() when all optional named parameters
are missing.
https://github.com/django/django/pull/12009 -- Fixed #23433 -- Deprecated
django-admin.py in favor of django-admin entry point.
https://github.com/django/django/pull/12181 -- Fixed #31062 -- Doc's
asgi.py in tutorials and project templates.
https://github.com/django/django/pull/11582 -- Fixed #23524 -- Allowed
DATABASES['TIME_ZONE'] option on PostgreSQL.
https://github.com/django/django/pull/11942 -- Fixed #20456 -- Added CBV
Testing docs
https://github.com/django/django/pull/12066 -- Removed unnecessary
dict.get() call in favor of direct indexing.
https://code.djangoproject.com/ticket/20935 -- ePub documentation not valid
https://code.djangoproject.com/ticket/30910 -- Add system check warning on
duplicate check constraints.
https://code.djangoproject.com/ticket/26424 -- Allow URLValidator to skip
schemes validation
https://code.djangoproject.com/ticket/30998 -- Make it easier to use the
model instance in ChoiceWidget.create_option()
Authored:
https://github.com/django/django/pull/12183 -- Moved selenium import to
nested scope.
https://github.com/django/djangoproject.com/pull/966 -- Updated Django to
2.2.8
Calendar Week 50 -- ending 15 December.
Triaged:
https://code.djangoproject.com/ticket/31082 -- New `Content-Disposition:
inline` header in FileResponse causing issues on Safari (Invalid)
https://code.djangoproject.com/ticket/31081 -- print query doesn't work
on multiple db environment with no default (Duplicate of #25947)
https://code.djangoproject.com/ticket/31055 -- Omits test_ prefix from
database name when running subset of tests. (Accepted)
Reviewed:
https://code.djangoproject.com/ticket/31071 -- Change in behaviour when
saving a model instance with an explcit pk value if the pk field has a
default
https://github.com/django/django/pull/11894 -- Fixed #30862 -- Allowed
setting SameSite cookies flags to 'None'.
https://github.com/django/django/pull/12211 -- Refs #23919 -- Used yield
from in inspectdb.
https://github.com/django/django/pull/12205 -- Fixed typo
"Followe" → "Follow".
https://github.com/django/django/pull/12189 -- Fixed typo in
ModelChoiceFieldTests.
https://github.com/django/django/pull/11811 -- Fixed #30585 -- Added {%
translate %} and {% blocktranslate %} template tags.
https://github.com/django/django/pull/12192 -- Rewrote simple JavaScript
example without jQuery
https://code.djangoproject.com/ticket/31073 -- SplitArrayField with
BooleanField always has widgets checked after the first True value.
https://code.djangoproject.com/ticket/31080 -- Remove redundant
type="text/javascript" attributes from script tags.
https://code.djangoproject.com/ticket/31076 -- dbshell crashes on Windows
and Python < 3.8.
https://github.com/django/django/pull/12195 -- Refs #23433 -- Fixed
test_django_admin_py.DeprecationTest tests failures on Windows and Python
< 3.8.
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/e8df107d-cb5a-47ee-8181-f5b16ea7e112%40googlegroups.com.
Re: Sounding out for GSoC 2020.
Hi Vineeth. There are a few third-party options in the space already. (Some linked from the thread I mentioned above. Others easily found via Google, "django 2fa".) I'd begin looking at those. I will write up a proper page for GSoC with the ideas here over the holiday period, but if you want an early start look at the "Students" section (and the following ones) from last year's page: https://code.djangoproject.com/wiki/SummerOfCode2019#Students Start looking at this: https://docs.djangoproject.com/en/dev/internals/contributing/ Make sure you're up and running with a development environment. Get to know Trac, even if only a little bit. And hang-out here and on the Forum https://forum.djangoproject.co — I want to leverage that for comms in 2020. Above all have fun! :) Welcome aboard Kind Regards, Carlton On Thursday, 19 December 2019 09:46:45 UTC+1, vineeth sagar wrote: > > Hi Carlton, > > I don't know if this is appropriate here or not. I will be starting > Master's this spring 2020(Jan) > > > I love the idea of 2FA. For first iteration I have an idea. While creating > a user we can ask for a 6 digit pin and whenever someone tries to login we > can make them input this pin. I have seen this implemented by a few > companies like Zerodha, UPI in India, these have a big customer base as > well. We can move towards more complicated ones with this as a starting > point. > > Moreover is there a reading list on what's expected of the 2FA, So I can > start drafting a proposal for this. I'll look at the rfc mentioned in the > thread for motivation and how it can be integrated to django. If there are > other latest sources it will be helpful. > > > Best, > Vineeth > > > On Thu, 19 Dec, 2019, 1:39 PM Asif Saif Uddin, > wrote: > >> As a long term user of django, I would love to see the DB/ORM + HTTP >> related improvements more in django and the schema migration improvements >> as I use django mostly for ORM and API/CMS based projects. >> >> I like the proposals of Adams related to ORM and inclusion of >> django-cors-headers to core. >> >> Beside the Idea of supporting 2FA, I think django should think about >> providing oauth2 support out of the box based on oauthlib and >> django-oauth-toolkit :) >> >> Definitely there could be better packages :) >> >> Just my thoughts as an long term user of django framework. >> >> Thanks, >> Asif >> >> On Thursday, December 19, 2019 at 4:51:06 AM UTC+6, Adam Johnson wrote: >>> >>> This year was interesting. Sage in particular did well putting together a cross-db JSONField, but he was probably under-mentored, since Mariusz has spent quite a bit of time reworking the PR, and still has a bit to go, before we can pull it in, hopefully for 3.1 So, one consideration we need to think about seriously is our capacity for mentoring. (This isn't just about the candidate's ability — Sage was able to implement all suggestions — we just didn't have as much capacity as we might have liked to think about the requirement implementation — and there were four of us actively giving some time each... — Anyhow, to think about.) >>> >>> I think your analysis is pretty accurate Carlton. Sage was a pretty >>> self-motivated candidate, writing some great blog posts about his code, and >>> we still didn't manage to merge his PR. Perhaps the project was larger than >>> we can reasonably expect? >>> >>> Nice work on the descriptions there Andrew. >>> >>> Django Service Hooks >>> >>> I think a key use case of this is background task processing. Nearly all >>> the Django integrated libraries need to remember to "connection.close()" / >>> "close_old_connections" at the end of requests. I've seen a couple in-house >>> ones that needed this. >>> >>> That said I can't think of much else to go inside the "service hook"? >>> There's not much else to "the end of a Django context" at the moment is >>> there? >>> >>> Evented Datastores >>> >>> I'm not sure if other databases have it but MariaDB recently implemented >>> "temporal tables" which are an SQL standard way of doing historical views >>> on data: https://mariadb.com/kb/en/library/temporal-data-tables/ >>> >>> Admittedly not quite the same as event sourcing but perhaps easier to >>> implement given it would be limited to the ORM layer. >>> >>> Django Benchmarking >>> >>> I love djangobench, and do wish it was maintained and expanded. Running >>> on CI would be amazing. >>> >>> >>> 2FA also sounds like a great idea. >>> >>> Other ideas: >>> >>>- Support MySQL/MariaDB storage engines. I think other databases >>>tend to support some table-level customizations to. >>>- Official CORS middleware/view decorator. I took over maintenance >>>of https://github.com/adamchainz/django-cors-headers and its design >>>is a bit pants. >>> >>> >>> On Sat, 14 Dec 2019 at 17:30, Andrew Godwin wrote: >>> Here's my
Re: Sounding out for GSoC 2020.
Hi Carlton, I don't know if this is appropriate here or not. I will be starting Master's this spring 2020(Jan) I love the idea of 2FA. For first iteration I have an idea. While creating a user we can ask for a 6 digit pin and whenever someone tries to login we can make them input this pin. I have seen this implemented by a few companies like Zerodha, UPI in India, these have a big customer base as well. We can move towards more complicated ones with this as a starting point. Moreover is there a reading list on what's expected of the 2FA, So I can start drafting a proposal for this. I'll look at the rfc mentioned in the thread for motivation and how it can be integrated to django. If there are other latest sources it will be helpful. Best, Vineeth On Thu, 19 Dec, 2019, 1:39 PM Asif Saif Uddin, wrote: > As a long term user of django, I would love to see the DB/ORM + HTTP > related improvements more in django and the schema migration improvements > as I use django mostly for ORM and API/CMS based projects. > > I like the proposals of Adams related to ORM and inclusion of > django-cors-headers to core. > > Beside the Idea of supporting 2FA, I think django should think about > providing oauth2 support out of the box based on oauthlib and > django-oauth-toolkit :) > > Definitely there could be better packages :) > > Just my thoughts as an long term user of django framework. > > Thanks, > Asif > > On Thursday, December 19, 2019 at 4:51:06 AM UTC+6, Adam Johnson wrote: >> >> This year was interesting. Sage in particular did well putting together a >>> cross-db JSONField, but he was probably under-mentored, >>> since Mariusz has spent quite a bit of time reworking the PR, and still >>> has a bit to go, before we can pull it in, hopefully for 3.1 >>> >>> So, one consideration we need to think about seriously is our capacity >>> for mentoring. (This isn't just about the candidate's ability — Sage was >>> able to implement all suggestions — we just didn't have as much capacity as >>> we might have liked to think about the requirement implementation — and >>> there were four of us actively giving some time each... — Anyhow, to think >>> about.) >>> >> >> I think your analysis is pretty accurate Carlton. Sage was a pretty >> self-motivated candidate, writing some great blog posts about his code, and >> we still didn't manage to merge his PR. Perhaps the project was larger than >> we can reasonably expect? >> >> Nice work on the descriptions there Andrew. >> >> Django Service Hooks >>> >> >> I think a key use case of this is background task processing. Nearly all >> the Django integrated libraries need to remember to "connection.close()" / >> "close_old_connections" at the end of requests. I've seen a couple in-house >> ones that needed this. >> >> That said I can't think of much else to go inside the "service hook"? >> There's not much else to "the end of a Django context" at the moment is >> there? >> >> Evented Datastores >>> >> >> I'm not sure if other databases have it but MariaDB recently implemented >> "temporal tables" which are an SQL standard way of doing historical views >> on data: https://mariadb.com/kb/en/library/temporal-data-tables/ >> >> Admittedly not quite the same as event sourcing but perhaps easier to >> implement given it would be limited to the ORM layer. >> >> Django Benchmarking >>> >> >> I love djangobench, and do wish it was maintained and expanded. Running >> on CI would be amazing. >> >> >> 2FA also sounds like a great idea. >> >> Other ideas: >> >>- Support MySQL/MariaDB storage engines. I think other databases tend >>to support some table-level customizations to. >>- Official CORS middleware/view decorator. I took over maintenance of >>https://github.com/adamchainz/django-cors-headers and its design is a >>bit pants. >> >> >> On Sat, 14 Dec 2019 at 17:30, Andrew Godwin wrote: >> >>> Here's my take on each of these, leaving out async as that'd be more >>> dependent on where we were: >>> >>> Secrets Manager >>> Many environments Django is deployed in use a separate secrets manager >>> to store and provide secrets per environment - either as environment >>> variables, files, or via a direct HTTP API. The project would be to design >>> and add an abstraction interface over secrets managers that allows users to >>> easily map to an external secret in a settings file. There's also room for >>> giving Django a better, built-in per-environments settings option too, >>> pulling from popular third-party patterns. >>> >>> Django Service Hooks >>> Django has a lot tied to the HTTP lifecycle, and if you run it outside >>> of this, you miss out on some key things - like database connections being >>> closed properly, or logging, or some middleware. The project would be to >>> design and implement a separate way of calling Django from a service >>> framework - even if that framework was itself HTTP based (basically, don't >>> rely on Django having to run through WSGI/ASGI)
Re: Sounding out for GSoC 2020.
As a long term user of django, I would love to see the DB/ORM + HTTP related improvements more in django and the schema migration improvements as I use django mostly for ORM and API/CMS based projects. I like the proposals of Adams related to ORM and inclusion of django-cors-headers to core. Beside the Idea of supporting 2FA, I think django should think about providing oauth2 support out of the box based on oauthlib and django-oauth-toolkit :) Definitely there could be better packages :) Just my thoughts as an long term user of django framework. Thanks, Asif On Thursday, December 19, 2019 at 4:51:06 AM UTC+6, Adam Johnson wrote: > > This year was interesting. Sage in particular did well putting together a >> cross-db JSONField, but he was probably under-mentored, >> since Mariusz has spent quite a bit of time reworking the PR, and still >> has a bit to go, before we can pull it in, hopefully for 3.1 >> >> So, one consideration we need to think about seriously is our capacity >> for mentoring. (This isn't just about the candidate's ability — Sage was >> able to implement all suggestions — we just didn't have as much capacity as >> we might have liked to think about the requirement implementation — and >> there were four of us actively giving some time each... — Anyhow, to think >> about.) >> > > I think your analysis is pretty accurate Carlton. Sage was a pretty > self-motivated candidate, writing some great blog posts about his code, and > we still didn't manage to merge his PR. Perhaps the project was larger than > we can reasonably expect? > > Nice work on the descriptions there Andrew. > > Django Service Hooks >> > > I think a key use case of this is background task processing. Nearly all > the Django integrated libraries need to remember to "connection.close()" / > "close_old_connections" at the end of requests. I've seen a couple in-house > ones that needed this. > > That said I can't think of much else to go inside the "service hook"? > There's not much else to "the end of a Django context" at the moment is > there? > > Evented Datastores >> > > I'm not sure if other databases have it but MariaDB recently implemented > "temporal tables" which are an SQL standard way of doing historical views > on data: https://mariadb.com/kb/en/library/temporal-data-tables/ > > Admittedly not quite the same as event sourcing but perhaps easier to > implement given it would be limited to the ORM layer. > > Django Benchmarking >> > > I love djangobench, and do wish it was maintained and expanded. Running on > CI would be amazing. > > > 2FA also sounds like a great idea. > > Other ideas: > >- Support MySQL/MariaDB storage engines. I think other databases tend >to support some table-level customizations to. >- Official CORS middleware/view decorator. I took over maintenance of >https://github.com/adamchainz/django-cors-headers and its design is a >bit pants. > > > On Sat, 14 Dec 2019 at 17:30, Andrew Godwin > wrote: > >> Here's my take on each of these, leaving out async as that'd be more >> dependent on where we were: >> >> Secrets Manager >> Many environments Django is deployed in use a separate secrets manager to >> store and provide secrets per environment - either as environment >> variables, files, or via a direct HTTP API. The project would be to design >> and add an abstraction interface over secrets managers that allows users to >> easily map to an external secret in a settings file. There's also room for >> giving Django a better, built-in per-environments settings option too, >> pulling from popular third-party patterns. >> >> Django Service Hooks >> Django has a lot tied to the HTTP lifecycle, and if you run it outside of >> this, you miss out on some key things - like database connections being >> closed properly, or logging, or some middleware. The project would be to >> design and implement a separate way of calling Django from a service >> framework - even if that framework was itself HTTP based (basically, don't >> rely on Django having to run through WSGI/ASGI). Initial idea is to provide >> a context manager that replaces the wrapping of a request, but the project >> would have to include requirements-gathering and interviewing people who >> use Django to power microservices to work out what they want. >> >> Evented Datastores >> Evented, or event-sourcing, database schemas are growing in popularity - >> essentially, a way to implement an append-only pattern on top of a >> relational database, where every single event that has happened is stored, >> but you can still efficiently retrieve the current state of an item. Given >> the way the pattern works, this would be possible to implement on top of >> Django models - likely as a whole new Model subclass - and implement with a >> matching QuerySet/Model API. It would require someone very skilled in >> database design, and it's also arguable if it should be in Django
