I agree. I do not know how this discussion on reloading of modules started. I never use. It is not in the book. One never needs it. I find it easy enough to restart web2py when I edit modules.
Massimo On Aug 31, 11:17 pm, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > On Aug 31, 10:48 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > Complaint #3: Having to do strange things (like double-imports and > > > reloads) to pick up run-time changes in my module. (This may be where > > > the complaint about 3rd party modules comes from.) > > > Response #3: I believe the issue here is that there is a module which > > > is being developed/debugged, but changes to it aren't getting picked- > > > up without re-starting the application (or doing "strange things"). > > > Were the module being developed located inside web2py during > > > development, then I believe edits would get picked up immediately. > > > As in ANY language is you change he source code of a module imported > > by a running application, the running application does not see the > > change. For debugging purposes you may want to force python programs > > to reload modules when they are used in case they have changed. Python > > provides a keyword for doing this: reload. You can use it in web2py, > > you do not have to. > > I'd suggest that use of 'reload' be discouraged as in process > reloading in any form can't be made to be 100% guaranteed to work. The > only reliable way is to restart the process. > > FWIW, Apache/mod_wsgi can be configured to auto detect changes and > restart the process automatically. This is covered in the mod_wsgi > documentation and have blogged previously about how to apply that to > Django on UNIX and Windows systems. > > http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode > > http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django... > http://blog.dscpl.com.au/2009/02/source-code-reloading-with-modwsgi-o... > > As usual, too busy to document or blog in exact detailt about how that > could be applied to web2py, but it isn't that hard. > > It would be entirely feasible to actually incorporate the code monitor > into web2py code base so all you needed to do during development is to > point it at different script file instead of wsgihandler.py. > > The gist of it would be to create wsgidevhandler.py. In that put the > monitor code from the mod_wsgi wiki page plus: > > from web2py.wsgihandler import application > > start(interval=1.0) > > You could also add calls to track() if web2py has non Python files > which aren't refreshed automatically and which need to trigger a > restart. > > Then point WSGIScriptAlias at wsgidevhandler.py instead of > wsgihandler.py and ensure you add an Allow directive for access to > that handler has well as what is already described in the book. For > example: > > <Directory /Users/grahamd/Testing/web2py> > AllowOverride None > Order Allow,Deny > Deny from all > <Files wsgihandler.py> > Allow from all > </Files> > <Files wsgidevhandler.py> > Allow from all > </Files> > </Directory> > > Okay, this means running Apache, but if you are deploying to Apache > then developing on same hosting arrangement is better anyway as you > will identify earlier anything which may work subtly different on what > will be your production system. > > Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
