Re: Refactoring the autoreloader

[Tom Forbes]

Thank you all for your feedback! I have fixed up my PR (
https://github.com/django/django/pull/8819) to add support for
watchman-based reloading, and it seems to be working well locally. After
further investigation I don't think using the Watchdog library is suitable
for Django, it seems to be un-maintained right now (which is a real shame).
Watchman seems to be faster even with constant reloading though, so I think
it's fine to just add support for that.

If anyone is interested they could take the changes to
`django/core/management/commands/runserver.py` and
`django/utils/autoreload.py`, and apply them to their installations. You
just need to install the `pywatchman` package + watchman itself, then run
manage.py with '--watchman'. I'd love some real-world feedback as to if
this improves reload speed and reduces CPU usage. Unfortunately Watchman
won't work on NFS volumes or virtualbox folders, so if you're using Vagrant
there isn't much that will help you here, which is also why we cannot make
this a default option - watchman will appear to work, but not pick up any
changes, if its run on such a volume.

I'll start work on adding documentation and tests next, but I'm quite lost
as to how I should test the Watchman integration. Should I be testing using
a real Watchman service, or should I mock it and hope that's enough?


On Thu, Oct 12, 2017 at 12:42 AM, Josh Smeaton 
wrote:

> I'd just like to second (or third) an appetite for this or a similar
> change. Lately I've started to notice very poor performance (high cpu
> usage, slow shutdowns, etc) with the django dev server on my project. I've
> moved to runserver_plus/werkzeug with watchdog in the mean time but it'd be
> good to have similar improvements via django natively.
>
> On Sunday, 8 October 2017 05:24:31 UTC+11, Aymeric Augustin wrote:
>>
>> Hello Tom,
>>
>> I think the PR is on the right track. Now it needs to be taken beyond the
>> "proof of concept" stage.
>>
>> Once you have code, docs, and if possibly some tests — currently there
>> are few due to the difficulty of testing auto reloading, especially edge
>> cases — for steps 1 and 2, I can review changes again and help you get it
>> merged.
>>
>> Since this is a major overhaul, we'll have to think carefully about how
>> the behavior changes and possible backwards incompatibilities. That said,
>> the autoreloader is a dev tool. Changing it isn't going to break anyone's
>> production. This makes the big-bang approach viable.
>>
>> Thanks for working on this!
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 29 Sep 2017, at 21:03, Tom Forbes  wrote:
>>
>> Hello,
>> I've been thinking on and off about how to improve the autoreloader
>> implementation and I wanted to gather some feedback on potential solutions.
>>
>> For some background, Django uses a fairly basic autoreload implementation
>> that simply polls the last modified time for loaded Python files once a
>> second. While this isn't the most efficient, it does work and has worked
>> quite well for a long time. When running manage.py runserver, the
>> autoreloader will launch a child "manage.py" with the same arguments and
>> this child process actually runs Django and serves requests. To reload, the
>> child process exits with exit code 3 and the parent restarts it. The code
>> is some of the oldest in Django, with a fair bit of it not touched in 9-12
>> years.
>>
>> While it works (and I'm a believer in "if it isn't broke don't fix it")
>> there are some architectural and performance issues with the current code:
>>
>> - Polling every second is not very efficient
>> - Detecting when the child process has exited during startup (i.e problem
>> in settings.py) is problematic and the code is rather nasty
>> - i18n files are 'reloaded' when they change in a rather hacky way
>> (resetting private attributes in another module)
>> - There is limited support for extending the current implementation, and
>> there are cases during development where the parent autoreloader will
>> terminate.
>>
>> I don't want this email to be too long, so I'm going to summarize what I
>> think would be a good approach to tackling these problems.
>>
>> 1. Refactor the current implementation by removing `pyinotify`, redundant
>> python 2 checks and implement a 'file_changed' signal so other parts of
>> Django can react to file changes (i.e the i18n module can handle resetting
>> it's own state).
>> 2. Add support for the "watchdog" library as a replacement for pyinotify.
>> Watchdog implements file system notifications for all major platforms using
>> a fairly simple API, so we can remove polling and have instant reloading.
>> Also support Watchman, a notification Daemon from Facebook.
>> 3. Add support for more advanced features, like proper handing of startup
>> errors and socket sharing.
>>
>> I've got a merge request that implements all three stages as a proof of
>> concept, but I think it's far too much a change to be done at once and
>> should be done carefully stage by stag

Easy prod setup for noobs

[Barnabas Szabolcs]

Hi guys,

you do an awesome job, developing Django, and I've used it for quite a few 
years. Still, always struggled how to get it reliably in production. (shame 
on me, I know...) 
Now, I have just come across an awesome tutorial that looks very robust, 
simple and elegant to me (and even a noob-ish person like me managed to 
make it work:P ):

http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/

maybe you could put something along these lines into your manual. So others 
will have less difficult time.
I don't know this guy, but I decided to drop a letter for him anyway, 
I reckon it could be a win-win for both of you..

Cheers,
Barney

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7aed54e4-1cb0-44e4-be4a-abba06a1707e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Easy prod setup for noobs

[Philip James]

Hey Barney! 

Thanks for reaching out. I think in general we are super careful about giving 
recommendations for hosting setups, because they things that end up in the 
official Django docs carry a lot of weight - sometimes more than we intend!

I think it’s unlikely we would include this today, but we have in the past 
tossed around the idea of a “recommended other resources” section. If that ever 
gets off the ground we could look at adding that there. 

Thanks again!

> On Dec 10, 2017, at 09:34, Barnabas Szabolcs  
> wrote:
> 
> Hi guys,
> 
> you do an awesome job, developing Django, and I've used it for quite a few 
> years. Still, always struggled how to get it reliably in production. (shame 
> on me, I know...) 
> Now, I have just come across an awesome tutorial that looks very robust, 
> simple and elegant to me (and even a noob-ish person like me managed to make 
> it work:P ):
> 
> http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/
> 
> maybe you could put something along these lines into your manual. So others 
> will have less difficult time.
> I don't know this guy, but I decided to drop a letter for him anyway, 
> I reckon it could be a win-win for both of you..
> 
> Cheers,
> Barney
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7aed54e4-1cb0-44e4-be4a-abba06a1707e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CB22C307-56EF-435D-9E72-52E37A6302F9%40philipjohnjames.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Roberth Solis Martínez]

Huuum it sounds cool

El martes, 17 de noviembre de 2015, 9:04:48 (UTC-6), Fabio Caccamo escribió:
>
> Hi guys, 
> I just released https://github.com/fabiocaccamo/django-admin-interface
>
> It is based on the great Elky's theme, but by default it uses the same 
> colors of https://www.djangoproject.com/ 
> and as a plus it allows some interface customizations (title, logo and 
> colors) directly through the admin interface itself.
>
> It's possible to manage multiple themes and switching between them with a 
> click.
> Here how the theme customization admin looks like:
>
>
> 
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/793e4ce8-7492-496c-84db-b22176a619b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.