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.html http://blog.dscpl.com.au/2009/02/source-code-reloading-with-modwsgi-on.html 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 -~----------~----~----~----~------~----~------~--~---
