[Web-SIG] again about logging in WSGI

[Graham Dumpleton]

On 24/11/2007, Manlio Perillo <manlio_perillo at libero.it> wrote:
> Graham Dumpleton ha scritto:
> > Whatever you do, please do not go releasing any distinct Python
> > module/package called 'mod_wsgi' as the Apache mod_wsgi code is all
> > set up around it being able to do that already, with the assumption
> > that it has ownership of that namespace because it started using the
> > name first.
>
> But this is a "no problem" :).
> A WSGI application can be embedded in Apache *or* in nginx.
>
> I would like to use a common name/interface so applications can easily
> be ported from Nginx to Apache and viceversa.

I am not sure you understood what I meant.

I already put out software called 'mod_wsgi'. This contains an Apache
module only.

I also already put out software called 'ap_swig_py'. The contents of
this when compiled and installed, will create in Python site-packages
directory a Python package called 'apache'. This contains SWIG
bindings for internal Apache APIs. It is usable from WSGI applications
running under Apache mod_wsgi. Technically the SWIG bindings are also
usable from mod_python, giving it much better access to internal
Apache APIs that it itself provides.

I also am preparing some software called 'mod_wsgi_py'. The contents
of this package when installed, will create in Python site-packages
directory a corresponding Python package called 'mod_wsgi', matching
the name of the Apache module. This package will contain a mix of
generic WSGI components as well as some which will only work when used
in the context of Apache mod_wsgi. In some cases the WSGI components
will use a generic mechanism when not run under Apache mod_wsgi, but
when Apache mod_wsgi is used a better more efficient mechanism will be
used which hooks in to the internals of Apache to do stuff. When
something hooks into Apache, it may be through using 'ap_swig_py'
bindings, or through direct C extensions custom built for the purpose.
However it is done, the intent is that it will be all transparent to
the code using it.

Examples of components that would be in the Python package installed
by 'mod_wsgi_py' would be things like a WSGI component for performing
a sub request back into the same Apache web server and then being able
to filter the response just like it was returned from any other WSGI
component. A component such as the ApacheLogHandler could also be
placed in this package, with Apache mod_wsgi, when the corresponding
Python mod_wsgi package was installed, triggering some initialisation
code which would install that as the root handler for the 'logging'
module, thus allowing the 'logging' module to log to Apache error logs
with levels specified by user code.

So, in other words, the 'mod_wsig_py' software would not be required
to use Apache mod_wsgi, but if you have it present, you will have
additional features. At the same time, you could use 'mod_wsgi_py'
even if you aren't running under Apache mod_wsgi, but could use it in
other WSGI hosting solutions, even under wsgiref server if you wanted
to. It would either replace components with something equivalent that
works outside of Apache, or the component wouldn't be available if no
other choice. This would be useful for testing or development outside
of Apache.

My concerns are that if you were to separately produce a package which
installs into site-packages a Python module or package called
'mod_wsgi' there will be a direct clash. The other concern is that if
you have followed the Apache mod_wsgi approach of internally creating
a  'mod_wsgi' Python module in sys.modules as a place holder and
storing of version information etc, then anyone using the installed
Python 'mod_wsgi' package from 'mod_wsgi_py'  wouldn't be able to run
their application with the nginx WSGI adapter. As your placeholder
will prevent it from being imported. In latest Apache mod_wsgi I do
various checks and only create the placeholder module if the real
package in site-packages is present.

Thus, to avoid problems you really want to be avoiding using the
'mod_wsgi' name in any Python context, whether that be in the names of
Python modules or as a prefix in the WSGI environment passed to
applications. Using the same name in your version as what Apache
mod_wsgi uses isn't going to gain you anything and because there will
inevitably be subtle differences or incompatibilities between the two,
using the same naming schemes will just make it harder where user code
does have to be able to distinguish between the two.

Graham