And in that regard, on a more general sense, I think web2py could use a notion of dev-vs-production modes. I know many people would implement things differently, but I think that if this be a core functionality, different modules could be used for different modes.
What we ended up doing, is qualifying the system's compute-name against a list of de-machine-names in the db model, for the same code to be usable in both dev and production machines. We use it for stuff like external-module-reloading on each request, which is essential for on-the-fly development. It's a retro-fit we should not have had to deal with, imho. We would have much rathered have web2py itself forcing a reload on any of our custom modules each time they changed, by (for example) deleting the .pyc files based on date-modified file-attributes or something of that sort. That can be easily be done as some kind of script-job that runs and checks a list of module files in a given folder for date-modifications and .pyc files existence, but only have it done in dev-mode. I think that static-assets should relate to that as well, but only in the context of dev-mode, which should exist anyway. --
