Re: Future of the development server's auto-reloading

2017-07-29 Thread Aymeric Augustin
Hello Tom, Your approach seems comprehensive. I'm commenting on your PR on Trac and GitHub. Let's do this! Regarding watchdog / watchman, I think Django could select automatically one or the other depending on which on is installed. If none is installed, Django would fall back to the current a

Re: Future of the development server's auto-reloading

2017-07-24 Thread Tom Forbes
I was looking into refactoring the auto-reloading code and I wanted to gather some feedback. There is some potential to squash several bugs in one go[1][2][3]. To begin with we can get rid of the Jython specific code, Jython is 2.7 only at the moment and I don't think that will change soon. We

Re: Future of the development server's auto-reloading

2017-01-04 Thread Tim Graham
So this idea doesn't get lost, I created a ticket for "Allow autoreloader to use watchman" https://code.djangoproject.com/ticket/27685#ticket On Monday, June 27, 2016 at 8:23:05 PM UTC-4, Tim Graham wrote: > > A pull request is proposed to add a new setting to allow specifying a > custom reloade

Re: Future of the development server's auto-reloading

2016-06-27 Thread Tim Graham
A pull request is proposed to add a new setting to allow specifying a custom reloader: https://github.com/django/django/pull/6719 Is this something anyone else would find useful and does it seems like we could continue support that option even if autoreloading is refactored based on the ideas

Re: Future of the development server's auto-reloading

2016-06-04 Thread Elf Sternberg
On Saturday, August 8, 2015 at 2:53:32 PM UTC-7, Aymeric Augustin wrote: > > Hello, > > While writing some horrific code [1] related to the development server’s > auto-reloading, I realized that its design is fundamentally flawed and I > think that we should reconsider it. > > The current imple

Re: Future of the development server's auto-reloading

2015-08-14 Thread Burhan
LiveReload[1] is one more to consider; what's more it already has examples for Django and other Python frameworks. It relies on Tornado (which may cause some dependency issues? would require testing) but it works. The only tweak that would be required would be to ensure that static files/media

Re: Future of the development server's auto-reloading

2015-08-10 Thread George Kappel
In case it is useful as a reference, runserver_plus from django-extensions uses Werkzeug/Watchdog for reloading http://django-extensions.readthedocs.org/en/latest/runserver_plus.html On Monday, August 10, 2015 at 12:15:46 PM UTC-5, Carl Meyer wrote: > > Hi Aymeric, > > I actually spent the PyC

Re: Future of the development server's auto-reloading

2015-08-10 Thread Carl Meyer
Hi Aymeric, I actually spent the PyCon 2015 sprints working on a generic watcher/reloader for Python servers, built on top of watchdog: https://github.com/carljm/wsgiwatcher It should still be considered alpha/prototype code, but I think the approach is promising. It uses a two-process model, whe

Re: Future of the development server's auto-reloading

2015-08-10 Thread Aymeric Augustin
Hello Sam, On 10 août 2015, at 11:34, Sam Cooke wrote: > I've thrown together a rough proof of concept[2] for runserver that uses > watchdog to watch for changes/additions/deletions to python files recursively > in the same directory as manage.py and restarts the server accordingly. It > coul

Re: Future of the development server's auto-reloading

2015-08-10 Thread Sam Cooke
Hi all, I've had experience playing around with watchdog[1] before - I've only ever used it on OS X but it should work cross platform. I've thrown together a rough proof of concept[2] for runserver that uses watchdog to watch for changes/additions/deletions to python files recursively in the same

Re: Future of the development server's auto-reloading

2015-08-09 Thread Daniel Moisset
The idea sounds awesome. A couple of corner cases that should be taken in consideration: - I think it is common for small simple projects (and people doing the tutorial) to have the sqlite db file in the same project directory. If we're watching for writes in every file in the project directory,

Re: Future of the development server's auto-reloading

2015-08-09 Thread Collin Anderson
This all makes sense to me, but it would be nice if it worked out of the box, especially for the purposes of the tutorial. :) On Saturday, August 8, 2015 at 5:53:32 PM UTC-4, Aymeric Augustin wrote: > > Hello, > > While writing some horrific code [1] related to the development server’s > auto-re

Re: Future of the development server's auto-reloading

2015-08-09 Thread Florian Apolloner
On Saturday, August 8, 2015 at 11:53:32 PM UTC+2, Aymeric Augustin wrote: > > - It doesn’t survive a syntax error in the settings module. I have reasons > to believe that this would be extremely messy to fix. > - If a module reads a configuration file on disk at startup and caches it, > the aut

Re: Future of the development server's auto-reloading

2015-08-09 Thread Tino de Bruijn
Hi Aymeric, While I have wondered from time to time why runserver could not just continue after certain syntax errors, and wished it could do so, I think what you are proposing makes a lot of sense. I think having to manually reload after installing a new package is really acceptable (and more an

Future of the development server's auto-reloading

2015-08-08 Thread Aymeric Augustin
Hello, While writing some horrific code [1] related to the development server’s auto-reloading, I realized that its design is fundamentally flawed and I think that we should reconsider it. The current implementation walks through the list of all imported Python modules, attempts to figure out