Graham Dumpleton wrote:
Hmmm, somehow I managed to vapourise an email, didn't even get
to my sent mail box. Let me try this again.
Jim Gallacher wrote ..
Graham Dumpleton wrote:
Correct, is actually done from the mod_python module init function.
The only way one could have it dynamically changing is through an
Apache -D option checked by using ap_exists_config_define().
This is incorrect. You can get at the directives from python_init. Proof
of concept patch attached. Apply the patch and add the following
directives in your apache config after the LoadModule.
LoadModule python_module /usr/lib/apache2/modules/mod_python.so
PythonModuleConfig max_locks 911
PythonModuleConfig mutex_dir /some/place/safe
Check the error.log for the results.
I'm sure I don't need to tell everyone that this is intend as Proof of
Concept only. Don't blame me if your hair catches on fire and your teeth
fall out as a result of using this patch. :)
I don't have much hair left, so I better believe you. Thus I stand
corrected. I also should look more closely at the code before I
send off email. :-)
If the settings are going to be a generic key/value like in
PythonOption, but only for purposes of the mod_python system itself,
maybe it should be called PythonSystemOption. Prefer PythonSystemOption
as "Module" is too confusing to me given you have both Apache modules
and Python modules and a module importer.
Fair enough. PythonSystemOption is a better. The directive definition is
such that it cannot be used in VirtualHost, Directory, Location and so
on which should help emphasize that it's use in only for configuring
mod_python.so initialization.
Also wary of "Config" because
of confusion with "req.get_config()".
Except that PythonSystemOption just stuffs strings into
server->module_config->directives table, which can be accessed via
req.server.get_config(). I can't see any reason application code will
ever need the settings PythonSystemOption might set, so it's not a big
deal if it's not obvious from the name that the settings can be
retrieved with get_config. I like the new name as it signals our
intention of how PythonSystemOption should be used. This name is also
consistent with PythonOption, which is a good idea.
Other than that, probably is reasonable. What other configuration things
are there like this that could be handled in the same way?
I don't know, but I'm sure other uses may arise. That's why I'd favour a
generic directive rather than a bunch of specific directives such as
PythonMutexDirectory, etc.
The key/value pairs generated when the PythonSystemOption directive is
encountered are simply placed in the same table as directives such as
PythonDebug and PythonPath. The difference is that these other
directives cause their respective functions to be called where other
processing, such as changing the debug flag, takes place.
Would it be
possible using such a thing to specify a directory that could be prefixed
to sys.path to say where mod_python Apache module should look for
mod_python Python modules?
If we modify the code to check the module_config->directives table for
an appropriate key/value pair, then sure, why not?
It is always a pain to debug sometimes
when people have multiple versions of Python and for various reasons
their Apache environment means it is finding wrong mod_python modules.
If had way of saying where it was, could override it as way of proving
one way or another it is a problem. Yes/No?
This new directive might be of use in other places if you want a way to
pass arbitrary key/value pairs from the apache config into mod_python.
Any code section that has access to the server_rec could make use of it.
Jim
