|
Home > Archive > Apache Mod-Python > May 2006 > Graham: Re Importer
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Graham: Re Importer
|
|
| Dan Eloff 2006-05-11, 7:12 am |
| > Depending on how your modules are structured, it may not be quite
> as bad as having to add it to every file. At least not the look up of
> what path to use.
>
> This is because what you may be able to do is use the fact that if
> you supply an absolute or relative path to apache.import_module(),
> that the "path" argument, rather than being a search path, becomes
> the path which is encoded into the module as '__info__.path'.
>
> Thus, if a top level entry point module were used, much like a
> package root, and although there were various sub modules that
> any methods were exposed through the top level module, you
> could do something like:
>
> # toplevel.py
>
> from mod_python import apache
> __info__.path.extend(eval(apache.main_server.get_options().get('my_im=
port_path','[]')))
>
> submodule_1 =3D apache.import_module('./submodule_1.py', path=3D__inf=
o__.path)
> submodule_2 =3D apache.import_module('./subdir_2/toplevel.py', path=
=3D__info__.path)
>
> Thus, those submodules now don't need to set '__info__.path', as they
> will inherit that from the top level module.
Excellent! I import ALL of my modules from pyserver modules (using
absolute paths), so all I really have to do is add the path. Don't
even need apache config, pyserver has it's own config file and I can
stick it in there. I'm going to try that in the morning.
> This may turn out to be messy or not useful as is as well. Overall, I
> guess what we need to come up with is some example use cases where
> search paths are required and perhaps work from that as to what is
> a good interface for supporting it. At the moment, my impression is
> that the common use case is in order to access some configuration
> module in a central location. Can you describe again your use case?
pyserver is a supporting framework for my websites, it handles
cookies, sessions (including a very secure two-tier session), database
connections (pooling & automatic rollback on exception), form
validation and error handling, templates, etc. So most of my modules
import at least one module from pyserver. I constantly am fiddling
with pyserver so the ability to autoreload and debug it is very nice.
I also have modules containing common functionality like login/logout
functions, email functions, and misc stuff that I like to access all
over the place. I want these things to autoreload, but I also want
them available from anywhere.
> One other issue that may come into play in this is that besides being
> able to access 'apache.main_server.get_options()', that is, the main
> server options, there is no way at global scope within a module to
> access the options related to the request, or virtual host that the
> module is being imported into.
>
> There was a similar issue in respect of the mod_python config settings
> for PythonDebug and PythonAutoReload when it came to the importer
> itself. To get around this the importer uses new top level dispatch
> functions to cache the appropriate configuration available so it is
> available no matter where apache.import_module() is used. At the
> moment this cached config isn't accessible through the 'apache' module
> but is available as 'mod_python.importer.get_config()'.
>
> If a module import is occurring do to PythonImport and you call that
> function, you will get the 'apache.main_server.get_config()' object. If
> the module import is occurring within the context of a request, the
> function will return 'req.get_config()'. Thus the 'apache.import_module()=
'
> function uses this to get the PythonDebug and PythonAutoReload
> settings so that they don't have to be explicitly passed to the function
> itself, thus avoiding some of the problems described in my issues list.
>
> I guess the question in respect of user options, is whether there should
> be some means getting the appropriate options object from global
> scope in a module. Thus, something like:
>
> from mod_python import apache
> __info__.path.extend(eval(apache.get_options().get('my_import_path','=
[]')))
>
> Where like with the config, if it is PythonImport, it returns the main
> server options and if in context of a request, the request options.
>
> The only problem with this is that you get back to unpredictable
> behaviour if a module might be imported from different places where
> the option set is different. That option set which is used first takes
> precedence.
Yikes. I'm having trouble wrapping my mind around the problems that
could spring up. I'd be one of those people holding the gun by the
trigger and peering down the barrel trying to figure out how it works.
I think if you want request options you should be getting them and
them only. Ditto for server options. It wouldn't be bad to have the
cached request options available at module scope and the server
options, but not through the same function.
> The issue is whether we want to protect people from doing stupid
> things by not allowing it, or give them a loaded gun and let them
> kill themselves if they want to. :-)
>
> Note, in Vampire, it actually for the time that a module is being
> imported exposes a variable '__req__' as global data within the module
> so that either the config, options or anything else for that matter about
> the request can be accessed. When I modified the Vampire importer for
> use in mod_python though, I didn't carry across that feature as was
> unsure about how wise it was providing it.
Yes not sure about the ramifications of that. A couple of times now
I've wished I could have that at global scope, but then I realized A)
it would cause more problems and B) there was a way around it that was
a better design.
> Sorry, I know this should be on the developer list. Maybe we should
> look at bumping it over there. Dan are you on the developer list?
Am now. 
| |
| Graham Dumpleton 2006-05-11, 7:12 am |
| Dan Eloff wrote ..
>
> pyserver is a supporting framework for my websites, it handles
> cookies, sessions (including a very secure two-tier session), database
> connections (pooling & automatic rollback on exception), form
> validation and error handling, templates, etc. So most of my modules
> import at least one module from pyserver. I constantly am fiddling
> with pyserver so the ability to autoreload and debug it is very nice.
> I also have modules containing common functionality like login/logout
> functions, email functions, and misc stuff that I like to access all
> over the place. I want these things to autoreload, but I also want
> them available from anywhere.
How does the need for a search path come into this? Is it these common
modules you mention in the last couple of sentences that are located
in some other location, which you want found by a path search but want
to be reloadable rather than being on sys.path?
Graham
| |
| Dan Eloff 2006-05-11, 1:12 pm |
| On 5/10/06, Graham Dumpleton <grahamd@dscpl.com.au> wrote:
> Dan Eloff wrote ..
>
> How does the need for a search path come into this? Is it these common
> modules you mention in the last couple of sentences that are located
> in some other location, which you want found by a path search but want
> to be reloadable rather than being on sys.path?
They are part of it, but there's only a few of them. There's a dozen
pyserver modules, and all of them have to be importable from any
module anywhere in my site, including those common modules. Currently
this is where I'm having trouble with using the import path as you
suggested. The website modules are being imported fine, they are using
the import path and finding both pyserver and the common modules.
However the the import path only works for modules one level deep, it
doesn't carry over so the common modules don't find pyserver. That's
easy enough to fix by using apache.import_module in the common
modules. I'm curious why you didn't let the import path propogate down
the import tree though.
-Dan
| |
| Graham Dumpleton 2006-05-11, 7:11 pm |
|
On 12/05/2006, at 3:52 AM, Dan Eloff wrote:
> On 5/10/06, Graham Dumpleton <grahamd@dscpl.com.au> wrote:
>
> They are part of it, but there's only a few of them. There's a dozen
> pyserver modules, and all of them have to be importable from any
> module anywhere in my site, including those common modules. Currently
> this is where I'm having trouble with using the import path as you
> suggested. The website modules are being imported fine, they are using
> the import path and finding both pyserver and the common modules.
> However the the import path only works for modules one level deep, it
> doesn't carry over so the common modules don't find pyserver. That's
> easy enough to fix by using apache.import_module in the common
> modules. I'm curious why you didn't let the import path propogate down
> the import tree though.
Don't propagate it down by default through either apache.import_module()
or "import" due to concerns arising from fact module could be imported
through two different routes and the inherited search path could be
different
through each route. Thus, the unpredictability that could arise if
such a
thing occurred. Overall, just being cautious until got feedback on how
people think it should work.
Graham
| |
| Dan Eloff 2006-05-12, 1:12 am |
| Probably best to err on the side of caution. I don't mind the way it
works now, and I'd rather have that than an unpredictable bug that
takes frustrating hour upon hour to solve.
-Dan
On 5/11/06, Graham Dumpleton <grahamd@dscpl.com.au> wrote:
>
> On 12/05/2006, at 3:52 AM, Dan Eloff wrote:
>
>
> Don't propagate it down by default through either apache.import_module()
> or "import" due to concerns arising from fact module could be imported
> through two different routes and the inherited search path could be
> different
> through each route. Thus, the unpredictability that could arise if
> such a
> thing occurred. Overall, just being cautious until got feedback on how
> people think it should work.
>
> Graham
>
|
|
|
|
|