I am on Unix, so the symbolic link will actually work. I'm going to
give that a shot, but it seems like this is something that's fairly
common for people to bump into...no?
The purpose of being able to get to private directories for a specific
context is mainly for config values like the DSN for the context's
database, site identifiers, different locations for data files and
images, and stuff along that nature. Right now, depending on the order
that the paths are inserted into the global sys.path, I just get every
context borrowing config values from the first context.
I hope that clarifies the reasons for why I want to do this a bit.
On Wednesday, October 9, 2002, at 05:10 PM, Ian Bicking wrote:
> On Wed, 2002-10-09 at 17:57, Steve Chen wrote:
>> Thanks for your reply. The problem still exists using what you
>> suggested below. So with the context configuration, I have:
>> 'context1': '/context1/www/', (needs to include some config values
>> private to context1)
>> 'context2': '/context2/www/' (needs to include some config values
>> private to context2)
>> I am wondering within context1 and context2, how do I add directories
>> into the sys.path that's only visible to THAT context. Doing that by
>> altering /context1/www/__init__.py and /context2/www__init__.py
>> to make changes to the global sys.path and not the specific context's.
>> Put another way, what I need to do is make an alteration to the
>> paths for a context private to that context.
>> It just seems like I am missing something basic here :)
> Oh... you're right, there's no good way to do that. sys.path is
> strictly global -- there's no way to change it for one context or
> servlet (without bad import-hook voodoo, which isn't worth it).
> I'm not sure if you're on Windows or Unix, but on Unix you could create
> a symbolic link to the directory you want to include under say
> /context1/www/ -- the other context could still do "import
> and get to it, but in context one you could do "import dir" and get the
> right directory.
> Otherwise you can simply name things differently... what's the problem
> you're trying to solve with this? There may be a better way to do it.