Re: [Web-SIG] about WSGI adoption
Graham Dumpleton ha scritto: [...] I think that the deployment must be done by the WSGI gateway/server and not by the application. That is, the application should only expose the callable object, and should not start a server, opening logging and configuration files, or stacking middlewares. This would require the WSGI adapter layer to encompass the means of loading the script file (as Python module) when required the first time. The only thing that really does it that way at present is mod_wsgi. Right. Current CGI-WSGI adapters expect the WSGI application entry point to effectively be in the same file as the main for the CGI script. Ie., Ok. [...] Anyway, hope this at least half illustrates that it isn't necessarily that simple to come up with one concept of having a single WSGI application script file which knows nothing about the means in which it is launched. In mod_wsgi it has made this as seamless as possible, but with other hosting mechanisms such as CGI, FASTCGI and SCGI where the WSGI adapter isn't actually embedded within the web server itself, but is within the process launched, it is much harder to make it transparent to the point where one could just throw a whole lot of WSGI application scripts in a directory and have it work. Not sure here. As an example, in the trac.fcgi example, the code that run the server can be moved to a separate file. It is true, however, that this make things more complicated, but maybe one can write a generic flup server launcher script: flup_run -p 4030 -b 127.0.0.1 -.script=/usr/local/bin/myapp.wsgi \ --application=application --protocol=fastcgi --daemon \ --user=x --group=x --log=/var/log/myapp.log [...] As an example, WSGI says nothing about what happens when an application module is imported (and the Python application process is created). And it can't easily do so as the differences in hosting technology make it hard to come up with one system which would work for everything. For some ideas put up previously, see thread about Web Site Process bus in: http://mail.python.org/pipermail/web-sig/2007-June/thread.html Thanks for the link. However a function called at module first import should suffice, for now. Some of the things that make it difficult are multi process web servers, plus web servers that only load applications on demand and not at the start when the processes are started up. The server can just execute the function when the module is imported (the problem is what should be done when the module script is reloaded in the same process). An application can execute startup code at module level, but a function is necessary since the application may need more informations from the web server (the log object, as an example). I don't see any problems with multiprocess web servers. Some hosting technologies from memory allow a logical application to be stopped and started within the context of the same process, whereas others don't. So, where as atexit() may be a reasonable of doing shutdown actions for some hosting technologies, it isn't for others. Ok. It can be useful if the gateway can execute an init_application(enviroment) function, where environment contains the same objects of the request enviroment, excluding the HTTP headers and the input object, and with a separate errors object. The closest you can probably get to portable application initialisation is for the application itself to track whether it has been called before and do something special if it hasn't. Even this is tricky because of multithreading issues. Logging is another thing that should be clarified. How should an application do logging? As an example for a WSGI gateway embedded in an existing server (like Apache and Nginx) it can be useful and convenient to keep logging in an unique log file. And if the server logging system uses log levels, this should be usable by the WSGI application. There is always the Python 'logging' module. Where things get interesting with this is how to configure the logging. Right, this is exactly the problem. But there is one more bigger problem: if I want to use the server logging (for Apache or Nginx) I have to use a non portable solution. In Pylons, provided you use 'paster', it will note that the .ini file mentions 'loggers' and so will push the config automatically to the 'logging' module. Run a Pylons application under mod_wsgi though and this doesn't happen so Pylons logging doesn't work. This is the reason why I think is it necessary to standardize a deployment method. Thus need to make the magic Pylons call to get it to push the config to the 'logging' module manually. Use of log levels is almost impossible. If using CGI your only logging mechanism is sys.stderr and that gets logged as ERR in Apache. Same for mod_wsgi, and similar for SCGI and FASTCGI I think. In mod_python its sys.stderr is
Re: [Web-SIG] about WSGI adoption
On Sun, Nov 18, 2007 at 09:03:23PM +0100, Manlio Perillo wrote: - Titus Brown ha scritto: - - - - However I still consider remarkable that there is not a trac.wsgi script. - - Can this be caused by the lack of a standardized deployment of WSGI - - applications? - - What would a trac.wsgi script contain? - - import trac.web.main - - application = trac.web.main.dispatch_request So this is something that can be 'execfile'd, I guess... - WSGI is a programming interface, - not a script interface like CGI. - - Right, but a WSGI server/gateway just needs a simple script to execute - the WSGI application. That might be useful for some WSGI deployment techniques and less useful for others. For example, if you're using an SCGI-based WSGI server, you need a command-line executable; for mod_python, you probably need an importable module with a function; for CGI, you need a CGI script; etc. So I think you're talking about something that is very specific to your own deployment technique. This is out of the scope of the WSGI proposal, for good reasons -- there are many ways of configuring and deploying WSGI apps and I don't know that we've settled on only one way. Paste is an effort to standardize deployment of WSGI applications, I think. cheers, --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] about WSGI adoption
Titus Brown ha scritto: On Sun, Nov 18, 2007 at 09:03:23PM +0100, Manlio Perillo wrote: - Titus Brown ha scritto: - - - - However I still consider remarkable that there is not a trac.wsgi script. - - Can this be caused by the lack of a standardized deployment of WSGI - - applications? - - What would a trac.wsgi script contain? - - import trac.web.main - - application = trac.web.main.dispatch_request So this is something that can be 'execfile'd, I guess... No. It provides an application callable that the WSGI gateway/server can execute. - WSGI is a programming interface, - not a script interface like CGI. - - Right, but a WSGI server/gateway just needs a simple script to execute - the WSGI application. That might be useful for some WSGI deployment techniques and less useful for others. For example, if you're using an SCGI-based WSGI server, you need a command-line executable; This is not fully correct. The sample script I have posted can be used by a SCGI-based WSGI server too. I think that the deployment must be done by the WSGI gateway/server and not by the application. That is, the application should only expose the callable object, and should not start a server, opening logging and configuration files, or stacking middlewares. for mod_python, you probably need an importable module with a function; for CGI, you need a CGI script; etc. So I think you're talking about something that is very specific to your own deployment technique. This is out of the scope of the WSGI proposal, for good reasons -- there are many ways of configuring and deploying WSGI apps and I don't know that we've settled on only one way. Right. But in the WSGI spec there is a propose to standardize a deployment method. As an example, WSGI says nothing about what happens when an application module is imported (and the Python application process is created). It can be useful if the gateway can execute an init_application(enviroment) function, where environment contains the same objects of the request enviroment, excluding the HTTP headers and the input object, and with a separate errors object. Logging is another thing that should be clarified. How should an application do logging? As an example for a WSGI gateway embedded in an existing server (like Apache and Nginx) it can be useful and convenient to keep logging in an unique log file. And if the server logging system uses log levels, this should be usable by the WSGI application. The same is valid for application configuration. Paste is an effort to standardize d eployment of WSGI applications, I think. Regards Manlio Perillo ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] about WSGI adoption
On 19/11/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Titus Brown ha scritto:
On Sun, Nov 18, 2007 at 09:03:23PM +0100, Manlio Perillo wrote:
- Titus Brown ha scritto:
- -
- - However I still consider remarkable that there is not a trac.wsgi
script.
- - Can this be caused by the lack of a standardized deployment of WSGI
- - applications?
-
- What would a trac.wsgi script contain?
-
- import trac.web.main
-
- application = trac.web.main.dispatch_request
So this is something that can be 'execfile'd, I guess...
No.
It provides an application callable that the WSGI gateway/server can
execute.
- WSGI is a programming interface,
- not a script interface like CGI.
-
- Right, but a WSGI server/gateway just needs a simple script to execute
- the WSGI application.
That might be useful for some WSGI deployment techniques and less useful
for others. For example, if you're using an SCGI-based WSGI server, you
need a command-line executable;
This is not fully correct.
The sample script I have posted can be used by a SCGI-based WSGI server too.
I think that the deployment must be done by the WSGI gateway/server
and not by the application.
That is, the application should only expose the callable object, and
should not start a server, opening logging and configuration files, or
stacking middlewares.
This would require the WSGI adapter layer to encompass the means of
loading the script file (as Python module) when required the first
time. The only thing that really does it that way at present is
mod_wsgi.
Current CGI-WSGI adapters expect the WSGI application entry point to
effectively be in the same file as the main for the CGI script. Ie.,
#!/usr/bin/python
def application(environ, start_response):
status = '200 OK'
output = 'Hello World!\n'
response_headers = [('Content-Type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
if __name__ == '__main__':
from paste.script.cgi_server import run_with_cgi
run_with_cgi(application)
This doesn't mean though that you couldn't develop a CGI-WSGI adapter
which separated the two parts, but not really easy to make it
completely transparent. This is because you still have to at least
create the CGI file which refers to the application script file in a
different location.
The Action directive in Apache can be made to make it a bit more
transparent by mapping a .wsgi or .py extension to a single CGI
script, with that script looking at the filename target of the request
to work out actual application file to load. Similar thing could be
done for FASTGCI and SCGI with Apache. Problem with this though is
that using Action directive in Apache in this way looses the correct
value for SCRIPT_NAME from memory. There is also no equivalent in
other servers such as lighttpd and nginx.
Anyway, hope this at least half illustrates that it isn't necessarily
that simple to come up with one concept of having a single WSGI
application script file which knows nothing about the means in which
it is launched. In mod_wsgi it has made this as seamless as possible,
but with other hosting mechanisms such as CGI, FASTCGI and SCGI where
the WSGI adapter isn't actually embedded within the web server itself,
but is within the process launched, it is much harder to make it
transparent to the point where one could just throw a whole lot of
WSGI application scripts in a directory and have it work.
In Python based web servers it gets more complicated again as in that
case it is the Python web server that is providing the top level URL
mapping to a WSGI application entry point, whereas in Apache, Apache
can do that automatically at least down to the initial entry point
before things go into Python code. One could technically write a
Python based web server whose top level URL to application mapping was
file system based like Apache is, but most probably wouldn't see the
point of it.
for mod_python, you probably need an
importable module with a function; for CGI, you need a CGI script; etc.
So I think you're talking about something that is very specific to your
own deployment technique. This is out of the scope of the WSGI
proposal, for good reasons -- there are many ways of configuring and
deploying WSGI apps and I don't know that we've settled on only one way.
Right.
But in the WSGI spec there is a propose to standardize a deployment method.
As an example, WSGI says nothing about what happens when an application
module is imported (and the Python application process is created).
And it can't easily do so as the differences in hosting technology
make it hard to come up with one system which would work for
everything. For some ideas put up previously, see thread about Web
Site Process bus in:
http://mail.python.org/pipermail/web-sig/2007-June/thread.html
Some of the things that make it
Re: [Web-SIG] about WSGI adoption
On 17/11/2007, Manlio Perillo [EMAIL PROTECTED] wrote: Manlio Perillo ha scritto: In these days I have to install a Trac instance. Trac needs a TRAC_ENV variable, and it seems that the only ways to set this variable is to: 1) Set the TRAC_ENV environment variable (CGI) 2) Use the TracEnv mod_wsgi option I found it remarkable that Trac does not has support for WSGI (as an example defining a `trac.trac_env` WSGI variable). My bad, Trac *has* such a variable: trac.env_path Unfortunately this is not documented. In fact http://trac.edgewall.org/wiki/TracModWSGI suggests to set the environment in the application script. FWIW, the Trac instructions on the Apache mod_wsgi site go into a lot more detail than those on the Trac site, including mentioning all the WSGI environment specific options. Graham ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
