On 6 avr, 12:01, Jonathan Lundell <jlund...@pobox.com> wrote: > It's worth reflecting on why this is the case. > > Ordinarily, in the Python environment, we'd solve this problem by adding our > local module repository to sys.path from inside the application, which would > work fine because the edited sys.path is local to the current instance of the > interpreter. But in a web2py environment, sys.path (and the interpreter) is > shared among all the applications.
This is the fact that the Python process is shared. web2py itself is the Python application. > > The brute-force solution, I think, is to run separate web2py instances, with > top-level routing in the external server (Apache, whatever). Yes, but this is not the way web2py is running by default. > > I can think of a couple of directions to look for alternatives. One is PEP > 302 (import hooks and such). Having a custom Python importer that will look in "modules" first before looking elsewhere would be a great solution. > A simpler approach would be for web2py to rebind sys.path to a thread-local > variable and add the app-specific modules directory to it. If that worked > (offhand I can't think why not, but > I'm no doubt missing something), it'd be pretty simple, as long as it didn't > get re-bound later, which is a hazard (note that web2py's idiom for adding to > sys.path rebinds it). A thread-local variable is not list. sys.path is expected to be a list. > > Going down that road, rather than rebinding sys.path to a thread-local > version, what if we added a thread-local member to sys.path that pointed to > the current application's modules directory? That'd be *really* simple, again > if I'm not missing something. I thought about it but a thread-local variable is not a string so we cannot add it to sys.path. So it is a problem.
