Add WSGIModuleAlias directive to allow direct mapping to Python module.

[GoogleCodeExporter]

The WSGIScriptAlias directive is used to map a URL to a script file which 
contains the WSGI 
application entry point. A script file is used to allow traditional Apache 
directory/file based access 
controls to be used. A script file is also used so that there is something 
which can be touched 
(modified) so as to trigger either a script reload or a process reload (if 
using daemon mode).

The use of a script file as target is also used in part to avoid the problems 
in mod_python 
whereby SCRIPT_NAME (the mount point) cannot be calculated properly and so WSGI 
adapters for 
mod_python have to set SCRIPT_NAME manually. This problem in mod_python is 
actually more to 
do with the fact though that it does not use an Alias like directive and 
instead relies on 
Directory/Location to specify the context that mod_python handler should be 
used. As such, its 
problems with SCRIPT_NAME come from not being able to always work it out 
correctly when 
using Directory/Location.

To some extent though the SCRIPT_NAME can though be deduced when using a 
directive like 
WSGIScriptAlias without having to have an actual file as target. This means it 
may be possible to 
have a Python module name, rather than a path as target of Alias like directive.

As such, look at feasibility and implement if possible a directive which allows 
for:

  WSGIModuleAlias /trac trac.web.main::dispatch_request

Where a WSGI application is able to be fully configured through the WSGI 
environment settings, it 
would allow configuration without having an actual script file. For example, to 
configure Trac you 
might use:

  WSGIDaemonProcess site-1 user=trac group=trac threads=25

  WSGIModuleAlias /trac trac.web.main::dispatch_request

  <Location /trac>
  WSGIProcessGroup site-1
  WSGIApplicationGroup %{GLOBAL}
  SetEnv trac.env_path /usr/local/trac/site-1
  </Location>

 If a pattern matching directive is also provided, could say something like:

  WSGIDaemonProcess site-1 user=user-1 group=user-1 threads=25
  WSGIDaemonProcess site-2 user=user-2 group=user-2 threads=25
  WSGIDaemonProcess site-3 user=user-3 group=user-3 threads=25
  WSGIDaemonProcess site-4 user=user-4 group=user-4 threads=25
  WSGIDaemonProcess site-5 user=user-5 group=user-5 threads=25
  WSGIDaemonProcess site-6 user=user-6 group=user-6 threads=25

  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/trac/([^/]+)
  RewriteRule . - [E=trac.process_group:%1,\
  E=trac.env_path:/usr/local/trac/sites/%1]

  WSGIModuleAliasMatch ^/trac/([^/]+) trac.web.main::dispatch_request

  <Location /trac>
  WSGIProcessGroup %{ENV:trac.process_group}
  WSGIApplicationGroup %{GLOBAL}
  </Directory>

In defining the target module, the mod_python convention could be used. If just 
a module name, 
then map to 'application', if however '::' is used, followed by a name, that 
name could be the 
name of object within module to be used as application entry point.

Do note however that since the purpose of the script file was so that it could 
be used as a trigger 
to restart the daemon process in daemon mode, that feature is given up and you 
would need to 
restart the whole of Apache, or identify the correct daemon processes for a 
particular application 
and send them a SIGINT. For a production site where restarting wouldn't 
normally be done 
anyway, this would be a reasonable loss of functionality for reduced level of 
configuration.

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 26 Mar 2008 at 10:13

[GoogleCodeExporter]

Note, to avoid confusion, the WSGIReloadMechanism argument of 'Module' should 
be changed to 'Script'. This 
shouldn't be a big deal as that is the default value and so no one would 
normally be setting it explicitly. In other 
words the name change shouldn't be noticed. Thus two reload mechanisms would be 
Script and Process, these 
being the defaults for embedded mode and daemon mode respectively, albeit that 
Process can only apply to 
daemon mode anyway. As described above, for WSGIModuleAlias however, no ability 
for anything to be reloaded 
as no script file available to check for changes.

Original comment by Graham.Dumpleton@gmail.com on 26 Mar 2008 at 10:29

[GoogleCodeExporter]

To be consistent with other directives in mod_wsgi, should probably not follow
mod_python convention for designating the callable object name, instead should 
use:

  WSGIModuleAlias /trac trac.web.main callable-object=dispatch_request

If one allows options like this on WSGI Alias directives, then could also allow
application-group and process-group to be defined as well. Thus Trac, 
configuration
would come down to:

  WSGIDaemonProcess site-1 user=trac group=trac threads=25

  WSGIModuleAlias /trac trac.web.main \
    callable-object=dispatch_request \
    process-group=site-1 application-group=%{GLOBAL}

  <Location /trac>
  SetEnv trac.env_path /usr/local/trac/site-1
  </Location>

and:

  WSGIDaemonProcess site-1 user=user-1 group=user-1 threads=25
  WSGIDaemonProcess site-2 user=user-2 group=user-2 threads=25
  WSGIDaemonProcess site-3 user=user-3 group=user-3 threads=25
  WSGIDaemonProcess site-4 user=user-4 group=user-4 threads=25
  WSGIDaemonProcess site-5 user=user-5 group=user-5 threads=25
  WSGIDaemonProcess site-6 user=user-6 group=user-6 threads=25

  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/trac/([^/]+)
  RewriteRule . - [E=trac.process_group:%1,\
  E=trac.env_path:/usr/local/trac/sites/%1]

  WSGIModuleAliasMatch ^/trac/([^/]+) trac.web.main \
    callable-object=dispatch_request \
    process-group=site-1 application-group=%{GLOBAL}

There is no way to set WSGI environment variables through an option and not 
sure I
want to go that direction, so Location directive or rewrite rule still required 
as shown.

If go this way of using options for process-group, application-group and
callable-object, could also logically allow them for WSGIScriptAlias directives 
as well.

As to module as target, could also introduce module variants of other 
directives such
as WSGIAuthUserModule, WSGIAuthGroupModule, WSGIAccessModule and 
WSGIImportModule.

Original comment by Graham.Dumpleton@gmail.com on 26 Mar 2008 at 11:23

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 7 Jul 2008 at 2:25

• Changed state: Started

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 7 Jul 2008 at 2:32

• Added labels: Milestone-Release3.0

[GoogleCodeExporter]

Splitting out the addition of process-group, application-group, callable-object 
and pass-authorisation options 
to WSGIScriptAlias directives as separate issue.

The original intent of having 'Module' variants of WSGIScriptAlias directives 
may not be feasible as in order to get 
SCRIPT_NAME to be set correctly requires overriding special translate phase of 
Apache as well as various other 
tricks. May not be worth the trouble.

Original comment by Graham.Dumpleton@gmail.com on 12 Jul 2008 at 1:12

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Milestone-Release3.0, Priority-Medium

[GoogleCodeExporter]

Decided that will not create module variants of directives.

Original comment by Graham.Dumpleton@gmail.com on 29 Oct 2008 at 10:51

• Changed state: WontFix