From: steve c. <st...@sc...> - 2002-10-08 07:03:22
|
Hi everyone. I am running into a problem in deploying multiple contexts with Webware. I have a directory structure that resembles something similar to this: /webware /webware/__init__.py = __all__ = ['lib'] /webware/lib/ (common library code shared by all contexts) then: /context1/www/ (actual templates) /context1/config/ (configuration files) and similarly: /context2/www/ (actual templates for context2) /context2/config/ (configuration files for context2) So with the /webware/__init__.py line, I don't have any trouble sharing the 'lib' module between my contexts. But I run into trouble with context1 and context2. If I add a __init__.py line that appends to the sys.path, I end up having /context1/config/ AND /context2/config/ in my sys.path. What am I doing wrong? Thanks! -s |
From: Ian B. <ia...@co...> - 2002-10-09 00:44:55
|
On Tue, 2002-10-08 at 02:03, steve chen wrote: > > Hi everyone. > > I am running into a problem in deploying multiple contexts with Webware. I have a directory structure that resembles something similar to this: > > /webware > /webware/__init__.py = __all__ = ['lib'] > /webware/lib/ (common library code shared by all contexts) > > then: > > /context1/www/ (actual templates) > /context1/config/ (configuration files) > > and similarly: > > /context2/www/ (actual templates for context2) > /context2/config/ (configuration files for context2) > > So with the /webware/__init__.py line, I don't have any trouble sharing the 'lib' module between my contexts. But I run into trouble with context1 and context2. If I add a __init__.py line that appends to the sys.path, I end up having /context1/config/ AND /context2/config/ in my sys.path. What am I doing wrong? The contexts are also added as packages, I believe. So you can be explicit and use "import context1.config.whatever". You shouldn't need to mess with sys.path -- and if you don't, I think this should work fine, though I'm not entirely clear on your file layout. Ian |
From: Steve C. <st...@sc...> - 2002-10-09 22:57:33
|
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 appears 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 include paths for a context private to that context. It just seems like I am missing something basic here :) -s On Tuesday, October 8, 2002, at 05:45 PM, Ian Bicking wrote: > On Tue, 2002-10-08 at 02:03, steve chen wrote: >> >> Hi everyone. >> >> I am running into a problem in deploying multiple contexts with >> Webware. I have a directory structure that resembles something >> similar to this: >> >> /webware >> /webware/__init__.py = __all__ = ['lib'] >> /webware/lib/ (common library code shared by all contexts) >> >> then: >> >> /context1/www/ (actual templates) >> /context1/config/ (configuration files) >> >> and similarly: >> >> /context2/www/ (actual templates for context2) >> /context2/config/ (configuration files for context2) >> >> So with the /webware/__init__.py line, I don't have any trouble >> sharing the 'lib' module between my contexts. But I run into trouble >> with context1 and context2. If I add a __init__.py line that appends >> to the sys.path, I end up having /context1/config/ AND >> /context2/config/ in my sys.path. What am I doing wrong? > > The contexts are also added as packages, I believe. So you can be > explicit and use "import context1.config.whatever". You shouldn't need > to mess with sys.path -- and if you don't, I think this should work > fine, though I'm not entirely clear on your file layout. > > Ian > > |
From: Ian B. <ia...@co...> - 2002-10-10 00:09:35
|
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 appears > 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 include > 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 context1.dir" 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. Ian |
From: Steve C. <st...@sc...> - 2002-10-10 08:00:37
|
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. Thanks, -s 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 >> appears >> 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 >> include >> 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 > context1.dir" > 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. > > Ian > > |
From: Ian B. <ia...@co...> - 2002-10-10 18:58:44
|
On Thu, 2002-10-10 at 03:00, Steve Chen wrote: > 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? I don't think I've tried to do it the way you are doing it. I would probably put the configuration values in a module like Context1Config, or I'd put them in a file that wasn't a module (just a text file of some sort), or I'd put the configuration for multiple contexts in one file, and use the context name as a key when I fetch config values. Ian |