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. :)
