automatic restart when Python code changes

Bug #213269 reported by Martijn Faassen
8
Affects Status Importance Assigned to Milestone
grok
Fix Released
High
Martijn Faassen
1.0
Fix Released
High
Martijn Faassen

Bug Description

We need to investigate automatically restarting Grok whenever a .py file changes. Other web frameworks do this by default. I'd suggest Grok also enables this by default, with perhaps an 'off' button (and other configuration of this behavior?) in our UI somewhere.

To implement this, we need to look at what TurboGears/Pylons/Django/Paste are doing and hopefully well be able to reuse code from one of them.

Revision history for this message
Kevin Teague (kevin-bud) wrote :

Here is the Django implementation (which was mostly taken from CherryPy), which just stats files every second in a seperate thread and causes a restart if a file has been modified:

http://code.djangoproject.com/browser/django/trunk/django/utils/autoreload.py

Revision history for this message
Philipp von Weitershausen (philikon) wrote : Re: [Bug 213269] Re: automatic restart when Python code changes

The 'paster serve' command from PasteDeploy also has something like
this built-in. I've used it in the past and it works nicely with Grok
when Grok is deployed as a WSGI app. It doesn't pick up modified ZCML
files, but then Grok doesn't really need you to modify those in the
first place.

Revision history for this message
Chris McDonough (chrism-plope) wrote :

I'd suggest running Grok via "paster serve" out of the box by default as a WSGI app. There's no need to reinvent or even cut-and-paste any wheels here.

Revision history for this message
Philipp von Weitershausen (philikon) wrote :

On 7 Apr 2008, at 16:15 , Chris McDonough wrote:
> I'd suggest running Grok via "paster serve" out of the box by
> default as
> a WSGI app. There's no need to reinvent or even cut-and-paste any
> wheels here.

Exactly

Revision history for this message
Peter Bengtsson (mail-peterbe) wrote :

How far are we with the paster serve progress? I've got an immediate solution that works that uses inotify if available otherwise works similar to django. I can push my hack into a formal patch with some help but if paster serve is going to replace the current runner within the nearest months I might as well take it easy.

My solution is at least very unintrusive and is able to distinguise .pt files that define METAL macros since changing these requires a zope restart.

Revision history for this message
Michael Haubenwallner (d2m) wrote :

There is a branch at http://svn.zope.org/grokproject/branches/d2m-dual-startup/
to support both startup modes (zopectl and paster serve).

Autorestart is available through paster like:

  bin/paster serve --reload etc/debug.ini

todd (todd-infrae)
Changed in grok:
assignee: nobody → faassen
milestone: none → 1.0
Revision history for this message
Martijn Faassen (faassen) wrote :

Brandon, looks like we got support for this now. I think we need to better document this in the tutorial though: Michael's "bin/paster serve --reload etc/debug.ini" needs to be mentioned prominently otherwise nobody will know. Feel free to reassign to Michael (d2m) if you can coordinate this with him too.

Changed in grok:
assignee: faassen → brandon-rhodes
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Brandon Rhodes (brandon-rhodes) wrote :

Martijn —

I have confirmed that this command indeed works! Per the comments above, do we want to abandon the little "g-ctl" and "g-debug" commands that currently hide paster from the developer? They don't even have useful help:

$ bin/g-ctl --help
No help available.
$ bin/g-debug --help
------
2009-01-19T16:01:58 WARNING root Developer mode is enabled: this is a security risk and should NOT be enabled on production servers. Developer mode can be turned off in etc/zope.conf
Welcome to the interactive debug prompt.
The 'root' variable contains the ZODB root folder.
The 'app' variable contains the Debugger, 'app.publish(path)' simulates a request.
>>>

And it's not clear to me what we're gaining by hiding the simple "paster serve etc/deploy.ini" command when they're going to have to use it anyway to get file reloading. Plus it makes us "look incompatible" and "look non-WSGI", in my opinion, when users are running a dinky little command whose name they do not recognize from the other web frameworks they use.

Also: when I document (maybe this evening, but probably later in the week), we need to mention that ---reload currently does *not* detect new files that need to be Grokked; it only reloads when it sees an existing file change.

Revision history for this message
Uli Fouquet (uli-gnufix) wrote :

I personally like the debugger (``g-debug`` in your example) pretty much and use it regularly, but maybe I just missed how to archive the same functionality with bin/paster.

Revision history for this message
Michael Haubenwallner (d2m) wrote :

described the --reload option in more detail in doc/tutorial.rst

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.