Re: A different approach for the auto-reloader

[natali...@gmail.com]

Hello everyone!

I'm conducting a PR cleanse crusade for the project, where I'll try move 
forward those PRs that still make sense or close them when appropriate. 
Were there other developments in this topic that would be relevant to make 
a decision about the PR[0]?

Thank you!
Natalia.

[0] https://github.com/django/django/pull/13154

On Wednesday, May 1, 2019 at 3:05:30 PM UTC-3 Adam Johnson wrote:

> 1. It’s really hard to know where a request is going at this level, so we 
>> could end up with a page view triggering 20 static files requests very 
>> quickly, which would lead to stating all files 20x redundantly.
>
>
> Indeed, maybe this could be solved with a re-stat cooldown?
>  
>
>> 2. How would we handle (potentially ridiculous) things like code imported 
>> from a thread during app ready? In general wouldn’t we need some kind of 
>> thread to poll for new imports to watch after Django has been started?
>
>
> This is less ridiculous than it sounds, I'm working on an APM package that 
> does something like this.
>
> On Wed, 1 May 2019 at 18:38, Tom Forbes  wrote:
>
>> Hey Ramiro,
>> This sounds like a pretty awesome idea in general. It would also solve 
>> one long standing issue where the http socket is closed and re-opened 
>> during reloading, leading to pageviews after code changes failing.
>>
>> I’m trying to think of some edge cases where we need to be careful, and 
>> there are three I can think of:
>> 1. It’s really hard to know where a request is going at this level, so we 
>> could end up with a page view triggering 20 static files requests very 
>> quickly, which would lead to stating all files 20x redundantly.
>>
>> 2. How would we handle (potentially ridiculous) things like code imported 
>> from a thread during app ready? In general wouldn’t we need some kind of 
>> thread to poll for new imports to watch after Django has been started?
>>
>> 3. Are there any workflows that would be disrupted by this? I can’t think 
>> of any that I use, but it’s possible that people have come to rely on the 
>> existing “does this throw an exception” in some cases, and triggering a 
>> request only to get this could be annoying?
>>
>> Overall though this feels like a good idea. Stat based reloaders are a 
>> lot simpler to deal with than platform specific fs monitoring. Ask thanks 
>> for the kind words about my refactor, I’m glad the abstractions work on 
>> something like this.
>>
>> Tom
>>
>> On 24 Apr 2019, at 05:33, Ramiro Morales  wrote:
>>
>> Hi all,
>>
>> I had a stab at a somewhat simpler development server automatic reloading 
>> strategy 
>> https://github.com/django/django/compare/master...ramiro:synch-reloader
>>
>> Intention is to test how an implementation of a design by Gary Bernhardt 
>> would look. The best written description I could find is this:
>>
>> https://github.com/devlocker/tychus/issues/3
>>
>> Gary also had posted some tweets (this is how I got interested in the 
>> topic) which seems to have been deleted since then.
>>
>> Main idea is: Actual checking of changes on the filesystem for modules 
>> under monitoring isn't performed in a loop or by depending on a OS kernel 
>> feature but per-HTTP request by a front-end proxy process which is in 
>> charge of restarting the 'upstream' web server process (in our case a 
>> dumbed-down runserver dev server) only when it detects there have been 
>> changes. 
>>
>> Been meaning to try this for some time. It would have been much harder 
>> before Tom Forbes' work on refactoring and cleaning up the reloading code 
>> for Django 2.2. IMHO Tom's code is so very well thought that for example I 
>> just had to lightly subclass StatReload to implement this totally different 
>> strategy.
>>
>> Current form of the code is a new experimental 'serverrun' (for lack of a 
>> better name) added to the Django code base whose command line UI mimics 
>> 100% the runserver one. 
>>
>> It copies code from a few places of our code base: The runserver command, 
>> the WSGI app hosting code, etc.
>>
>> I decided to implement this as a new built-in command for now a) to ease 
>> experimentation and b) because it needs some minor changes to the 
>> 'runserver' command to handle cosmetic details (logging). If the idea is 
>> accepted (read further below for reasons in favor of this) then maybe we 
>> can switch runserver to this code. Or if the idea isn't deemed appropate 
>> for Django core them I might implement it as an standalone django 
>> app/project.
>>
>> If the idea of a smarter stat()-based FS status monitor like this gets 
>> actually tested and validated in the field (i.e. by users with big source 
>> code trees) it could allow us to possibly stop needing to depend on all of:
>>
>> * watchman
>> * pyinotify
>> * watchdog
>> (and removing our support code for them from the Django code base).
>>
>> Also, this would mean:
>>
>> * Setup simplification for final users (no third party Python libraries 
>> or system daemon to install)
>> * Better cr

Re: Can we move the activity on this list to the Forum now?

[natali...@gmail.com]

Hello everyone!

I was wondering if we could make a decision about this topic. On the one 
hand, and as far as I understand, the forum is the preferred channel of 
communication. On the other hand, having multiple channels of communication 
can spread important discussions too thin, making it difficult to have 
productive conversations in one place.

As a newcomer to the contributing community, I can attest that the current 
situation causes some confusion. IMHO, the same applies to the chat 
options: there is IRC and the Discord server (though perhaps I should start 
a new forum topic about that in order to keep decisions separated).

In summary, I'm +1 to "move on-mass (all few of us :) over there"!

Thank you!
Natalia.

On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:

> I just submitted a proposal to create a Discourse plugin to improve the 
> accuracy of their inbound email parsing. This would enable two things:
>
>- Folks who prefer to live in their inbox could continue to do so and 
>contribute by just replying to emails. Discourse currently has 
>reply-by-email, but it often mangles formatting and/or entirely deletes 
>text. Once these issues are fixed, folks who like the current experience 
>would be able to just pretend the forum doesn't exist and continue having 
>the same experience as they currently have with Google Groups.
>- Right now importing the archives from Google Groups into Discourse 
>isn't realistic for the same reasons; some messages will import correctly, 
>but others will be mangled or missing text. This would also be made 
>possible.
>
> If this is something you care about (positively or negatively), here is 
> the exploratory proposal:
>
>
> https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944
>
> Any feedback and/or testing would be much appreciated! Right now Discourse 
> recognizes that this is a problem and is interested in solving it, but 
> getting it prioritized will require folks to A) speak up saying they want 
> it done B) test the underlying API to verify that it actually solves the 
> problem.
>
> Alex
>
> On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson  
> wrote:
>
>> OK, I've updated the Trac wiki page to point to the forum too. (We use 
>> this as a wiki-link in responses to guide folk onwards.) 
>>
>> The docs have a `|django-developers|` shortcut used in quite a few places 
>> so that needs a moment more to review and adjust. 
>> (I'll look at it soon-ish... — if no-one beats me to it :) 
>>
>> Thanks. 
>> C
>>
>> On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
>>
>>> We should at least update those Trac and Triage Workflow docs to point 
>>> to both, maybe with the Forum first?
>>>
>>> Andrew
>>>
>>> On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:
>>>
>>> I'm trying to begin new conversations there where I can. 
>>>
>>> The main issue is that we're still pointing people here from Trac and 
>>> the Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can 
>>> adjust practice there. 
>>>
>>> I expect there will always be the "How do I start?" posts. The Forum at 
>>> least has a pinned post for that. ... 
>>>
>>> On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers 
>>> (Contributions to Django itself)  wrote:
>>>
>>> Hi all,
>>>
>>> I find that the signal-to-noise ratio on this mailing list is (by my 
>>> determination) quite bad around this time of year.
>>>
>>> Is a move to the forum still on the cards? 
>>>
>>> Kye
>>> On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin , 
>>> wrote:
>>>
>>> I did some investigation of moving django-users and django-developers to 
>>> the Forum right after DjangoCon; I wanted to see if we could import all the 
>>> old posts too, which we probably could, but I'm not entirely sure of the 
>>> utility of that. 
>>>
>>> I will say that the forum is a lot easier to moderate - the ability to 
>>> moderate after a post has gone out, rather than gating all posts behind 
>>> approval if they're untrusted, is a big step in itself, not to mention the 
>>> ability to remove sensitive or offensive content once it's posted.
>>>
>>> Andrew
>>>
>>> On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au wrote:
>>>
>>> IMO django-announce and django-updates serve a very different purpose 
>>> and I would be against moving them if it were suggested.
>>>
>>> I am incredibly strongly in favour of moving django-developers and 
>>> django-users to the forums. IMO being able to more easily trap people 
>>> misusing this list as a tech support channel is itself reason enough to 
>>> move. Beyond that, I’d argue that the plentiful UX issues with Google 
>>> Groups, and mailing lists in general, certainly don’t do the community any 
>>> favours in terms of getting more people on board. 
>>>
>>> Kye
>>>
>>> On 28 Nov 2022 at 11:40 PM +0800, 'Tobias McNulty' via Django developers 
>>> (Contributions to Django itself) 

Re: Can we move the activity on this list to the Forum now?

[natali...@gmail.com]

I'm also available to do some moderation in the forum. I'll try to chase 
getting moderator perms to help!

On Saturday, May 6, 2023 at 5:09:51 AM UTC-3 Carlton Gibson wrote:

> Hey Curtis. 
>
> The notifications settings are very flexible, and allow good filtering (to 
> your inbox) if that's how you want them. 
>
> For example, I'm able to get notifications for the Django Internals 
> category, and the Async subcategory of Using Django (and then I'm able to 
> keep up with the rest just by glancing at the latest tab.) 
>
> The water is nice  😅
> C.
>
>
> On Thu, 4 May 2023 at 07:29, Curtis Maloney  wrote:
>
>> Does the Forum allow me to get email notifications / summaries?
>>
>> If not, it will mean I disconnect with that part of the community.
>>
>> --
>> Curtis
>>
>> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>>
>> Yes please!
>>
>>
>>
>> On May 3, 2023 at 11:19:12 PM, jure.er...@gmail.com (jure.er...@gmail.com) 
>> wrote:
>>
>>
>> +1
>>
>>  
>>
>> *From:* django-d...@googlegroups.com  *On 
>> Behalf Of *natali...@gmail.com
>> *Sent:* sreda, 03. maj 2023 20:10
>> *To:* Django developers (Contributions to Django itself) <
>> django-d...@googlegroups.com>
>> *Subject:* Re: Can we move the activity on this list to the Forum now?
>>
>>  
>>
>> Hello everyone!
>>
>>  
>>
>> I was wondering if we could make a decision about this topic. On the one 
>> hand, and as far as I understand, the forum is the preferred channel of 
>> communication. On the other hand, having multiple channels of communication 
>> can spread important discussions too thin, making it difficult to have 
>> productive conversations in one place.
>>
>>  
>>
>> As a newcomer to the contributing community, I can attest that the 
>> current situation causes some confusion. IMHO, the same applies to the chat 
>> options: there is IRC and the Discord server (though perhaps I should start 
>> a new forum topic about that in order to keep decisions separated).
>>
>>  
>>
>> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>>
>>  
>>
>> Thank you!
>>
>> Natalia.
>>
>> On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:
>>
>> I just submitted a proposal to create a Discourse plugin to improve the 
>> accuracy of their inbound email parsing. This would enable two things:
>>
>>- Folks who prefer to live in their inbox could continue to do so and 
>>contribute by just replying to emails. Discourse currently has 
>>reply-by-email, but it often mangles formatting and/or entirely deletes 
>>text. Once these issues are fixed, folks who like the current experience 
>>would be able to just pretend the forum doesn't exist and continue having 
>>the same experience as they currently have with Google Groups.
>>- Right now importing the archives from Google Groups into Discourse 
>>isn't realistic for the same reasons; some messages will import 
>> correctly, 
>>but others will be mangled or missing text. This would also be made 
>>possible.
>>
>> If this is something you care about (positively or negatively), here is 
>> the exploratory proposal:
>>
>>  
>>
>>
>> https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944
>>
>>  
>>
>> Any feedback and/or testing would be much appreciated! Right now 
>> Discourse recognizes that this is a problem and is interested in solving 
>> it, but getting it prioritized will require folks to A) speak up saying 
>> they want it done B) test the underlying API to verify that it actually 
>> solves the problem.
>>
>>  
>>
>> Alex
>>
>>  
>>
>> On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson  
>> wrote:
>>
>> OK, I've updated the Trac wiki page to point to the forum too. (We use 
>> this as a wiki-link in responses to guide folk onwards.) 
>>
>>  
>>
>> The docs have a `|django-developers|` shortcut used in quite a few places 
>> so that needs a moment more to review and adjust. 
>>
>> (I'll look at it soon-ish... — if no-one beats me to it :) 
>>
>>  
>>
>> Thanks. 
>>
>> C
>>
>>  
>>
>> On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
>>
>> We should at least update those Trac and Triage Workf

Fellow Reports - May 2023

[natali...@gmail.com]

Week ending 2023-05-07 (week 19)

Triaged:
  https://code.djangoproject.com/ticket/34531 - Rendering form throws 
deprecation warning (invalid)
  https://code.djangoproject.com/ticket/34539 - `get_prep_value` no longer 
called for JSONField (accepted with ongoing conversations)
  https://code.djangoproject.com/ticket/34540 - [feature request] Run 
FileField storage callable during runtime and not during buildtime (wontfix)
  https://code.djangoproject.com/ticket/34542 - Required fields not 
enforced when interactively using createsuperuser (invalid)
  https://code.djangoproject.com/ticket/34543 - Thousand separator breaking 
templates (needsinfo)

Commented on:
  https://code.djangoproject.com/ticket/32827 - Squashing migrations isn't 
very effective in complicated projects; rewrite docs to provide a preferred 
manual trimming process

Reviewed:
 https://github.com/django/django/pull/16820 - Fixed #34529, Refs #34525 -- 
Reduced index operations with Meta.indexes/index_together when optimizing 
migrations.
  https://github.com/django/django/pull/16822 -  Update tutorial04.txt to 
make location of change explicit
  https://github.com/django/django/pull/16777 - Fixed #12780 -- Added 
compound form/formset validation in ModelAdmin
  https://github.com/django/django/pull/16592 - Fixed #30386 -- Fixed 
primary key quoting in admin related object links.

Reviewed and landed:
  https://github.com/django/django/pull/16821 - Fixed #34530 -- Improved 
docs when customizing storage for FileField.
  https://github.com/django/django/pull/14499 - Refs #31369 -- Improved 
hint message in NullBooleanField's deprecation warning.

PR Cleanup
  https://github.com/django/django/pull/14783 - Tab completion when 
executing as `./manage.py`

Other/Misc:
  Watched and learnt from Mariusz while he released Django 4.2.1, 4.1.9 and 
3.2.19.
  Resurfaced conversation on (completing?) migrating to the forum, still 
unclear how that'll continue.
  DjangoCon US flight tickets! :tada:

-- 
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/0cb0d6fe-fd09-4c91-b32c-9b54d8219d7bn%40googlegroups.com.

Re: Fellow Reports - May 2023

[natali...@gmail.com]

Hello everyone!

I've posted my fellow report in the 
forum: https://forum.djangoproject.com/t/django-fellow-report-natalia/20942
Following reports will be threaded in that topic \o/

Thank you! Natalia.

On Monday, May 8, 2023 at 9:33:15 AM UTC-3 natali...@gmail.com wrote:

> Week ending 2023-05-07 (week 19)
>
> Triaged:
>   https://code.djangoproject.com/ticket/34531 - Rendering form throws 
> deprecation warning (invalid)
>   https://code.djangoproject.com/ticket/34539 - `get_prep_value` no 
> longer called for JSONField (accepted with ongoing conversations)
>   https://code.djangoproject.com/ticket/34540 - [feature request] Run 
> FileField storage callable during runtime and not during buildtime (wontfix)
>   https://code.djangoproject.com/ticket/34542 - Required fields not 
> enforced when interactively using createsuperuser (invalid)
>   https://code.djangoproject.com/ticket/34543 - Thousand separator 
> breaking templates (needsinfo)
>
> Commented on:
>   https://code.djangoproject.com/ticket/32827 - Squashing migrations 
> isn't very effective in complicated projects; rewrite docs to provide a 
> preferred manual trimming process
>
> Reviewed:
>  https://github.com/django/django/pull/16820 - Fixed #34529, Refs #34525 
> -- Reduced index operations with Meta.indexes/index_together when 
> optimizing migrations.
>   https://github.com/django/django/pull/16822 -  Update tutorial04.txt to 
> make location of change explicit
>   https://github.com/django/django/pull/16777 - Fixed #12780 -- Added 
> compound form/formset validation in ModelAdmin
>   https://github.com/django/django/pull/16592 - Fixed #30386 -- Fixed 
> primary key quoting in admin related object links.
>
> Reviewed and landed:
>   https://github.com/django/django/pull/16821 - Fixed #34530 -- Improved 
> docs when customizing storage for FileField.
>   https://github.com/django/django/pull/14499 - Refs #31369 -- Improved 
> hint message in NullBooleanField's deprecation warning.
>
> PR Cleanup
>   https://github.com/django/django/pull/14783 - Tab completion when 
> executing as `./manage.py`
>
> Other/Misc:
>   Watched and learnt from Mariusz while he released Django 4.2.1, 4.1.9 
> and 3.2.19.
>   Resurfaced conversation on (completing?) migrating to the forum, still 
> unclear how that'll continue.
>   DjangoCon US flight tickets! :tada:
>

-- 
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/877c65a9-6e43-425e-aeb7-9533dc527120n%40googlegroups.com.

Re: (Circa end of 2021) Localization issues with input type=date?

[natali...@gmail.com]

On Thursday, November 10, 2022 at 5:40:45 AM UTC-3 Jacob Rief wrote:

How about ditching the JS based datepicker altogether and replace it 
against the built-in datepicker offered by modern browsers? This would also 
help users of mobile devices because they already have good internal 
implementations to select a date. I agree that on desktop browsers the 
built-in datepicker does not really look nice, but IMO still works way 
better than the  widget, (ab-)used for date types as 
currently implemented in Django. 

A compromise for the Django Admin could be to detect the CSS query "@media 
(pointer:coarse)". If this matches, it's a mobile device and we can fall 
back on the internal date selector. Otherwise use a nice looking JS 
implementation.

There is a good article on CSS Tricks about date input types:
https://css-tricks.com/better-form-inputs-for-better-mobile-user-experiences/#aa-a-quick-detour-into-date-types

Btw., since PR#15806  is 
stale, may I reclaim it?


I have pinged the original author asking if they can continue, if they 
can't or do not reply in a few weeks, please do so!

-- 
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/162c8ff3-968a-4e88-b364-6018adcdbf2cn%40googlegroups.com.