On Apr 6, 2011, at 10:01 AM, Jonathan Lundell wrote:
>
> On Apr 6, 2011, at 9:36 AM, pierreth wrote:
>>
>>> 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.
>
> Indeed. I thought I might be missing something, and that's it: the perennial
> problem with thread-local constructs.
How about this, as a means of adding the app-specific modules/ to sys.path: in
a thread-local object 'localthing', store the path to the current application's
modules/ directory in something.modules.
Subclass str thus:
class LocalModules(str):
def __str__(self):
return str(localthing.modules)
In the web2py startup logic:
sys.path.append(LocalModules("modules")) # the value isn't important, though it
could be used to generalize this construct
In the web2py request logic:
something.modules = <path to current application's modules directory>
This could be generalized somewhat by having LocalModules get the real string
("modules" in this example) from super, and fetch the attribute of that name
from localthing.
