Graham: Re Importer

[Dan Eloff <da...@gmail.com>]

> 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_import_path','[]')))
>
>     submodule_1 = apache.import_module('./submodule_1.py', path=__info__.path)
>     submodule_2 = apache.import_module('./subdir_2/toplevel.py', path=__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. :)