A more useful command-line wsgiref.simple_server?
Currently, calling wsgiref.simple_server simply mounts the (bundled) demo app. I think that's a bit of a lost opportunity: as the community has mostly standardized on a *.wsgi/wsgi.py script providing an `application` name in its global namespace, it would be nice if wsgiref.simple_server could take such a file as parameter and mount the application provided: * This would allow testing that the script has no error without having to go through mounting it in e.g. mod_wsgi * It would make trivial/test applications (e.g. dynamic responders to local JS) simpler to bootstrap as there would be no need for the half-dozen lines of wsgiref.simple_server bootstrapping and "hard" dependency on wsgiref, import wsgiref.simple_server def application(environ, start_response): 'code' if __name__ == '__main__': httpd = make_server('', 8000, application) httpd.serve_forever() could become: def application(environ, start_response): 'code' Since wsgiref already supports `python -mwsgiref.simple_server`, the change would be pretty simple: * the first positional argument is the wsgi script if it is present it is `exec`'d, the `application` key is extracted from the locals and is mounted through make_server; if it is absent, then demo_app is mounted as before * the second positional argument is the host, defaulting to '' * the third positional argument is the port, defaulting to 8000 This way the current sanity test/"PHPInfo" demo app works as it did before, but it becomes possible to very easily serve a WSGI script with almost no overhead in the script itself. Thoughts?
On Wed, Mar 28, 2012 at 2:37 PM, Masklinn <masklinn@masklinn.net> wrote:
I remember the pain of using HTTPServer, CGIHTTPServer and friends just to test a few html pages through a local browser, so I hear you. Unfortunately, bug tracker is down for the maintenance for me to search for similar reports for these libraries.
it would be nice if wsgiref.simple_server could take such a file as parameter and mount the application provided:
+2
All points valid. That was also my use case for the CGI/HTTPServers.
Since wsgiref already supports `python -mwsgiref.simple_server`, the change would be pretty simple:
Is it possible to choose a more intuitive name if it is for Python 3.3 only anyway?
To summarize: python -m wsgiref.simple_server [[wsgi_script.py] [[host] [port]]] A better way: python -m wsgiref.simple_server <wsgi_script[.py][:application]> [-h host] [-p port] But for good API it would be nice to see an overview of command line params of other WSGI servers for some kind of convention.
1. Even more awesome if any WSGI application could be tested (bootstrapped) this way. 2. Let test/"PHPInfo" serve forever and add few more tabs (pyrasite for the current Python?) -- anatoly t.
On 2012-03-28, at 15:03 , anatoly techtonik wrote:
The wsgiref module has not changed on that point in Python 3 (wsgiref.simple_server is still wsgiref.simple_server), so adding behavior would be done to the same place.
actually, python -m wsgiref.simple_server [wsgi_script [host [port]]]
<wsgi_script[.py][:application]>
I don't think that is a good idea: 1. WSGI scripts don't have to have any extension or can have no extension at all (as far as I can tell, many scripts follow mod_wsgi by using a .wsgi extension) 2. Not sure why the application name would be editable, this adds needless complexity and it does not seem supported by the most populat deployment method (mod_wsgi) 3. Finally, this changes the current behavior mounting the demo app by default, which I'd rather not do unless stdlib maintainers assert it should be done. So just [wsgi_script]
[-h host] [-p port]
I'd rather not burn help's -h for host specification. Are there really so many situations where you'd want to specify a port and leave the default host?
Well as far as I can tell, most WSGI applications which can work single-threaded would work with just that.
On Wed, Mar 28, 2012 at 4:30 PM, Masklinn <masklinn@masklinn.net> wrote:
I can't see why it can not be something like: python -m wsgiref ... Making wsgiref provide a server is an intuitive guess. Non-intuitive part is that running `wsgiref` doesn't give a hint where to find this server.
All right. Let's drop [.py]
I don't use `mod_wsgi` deployment, and can't confirm your popularity rating. I use AppEngine - it uses `app` in example: https://developers.google.com/appengine/docs/python/python27/using27#Configu... gunicorn uses `app` also: http://pypi.python.org/pypi/gunicorn `wsgiref` doesn't place any restriction on callable name, so why hardcode it to `application`. Let it do discovery itself or make the callable name explicit (you know - it's better).
Well, makes sense, but how do you know that server_example has parameters? It may be better to leave a --demo argument if somebody needs a demo.
I forgot that -h is for --help. `-H host[:port]` may be a better notation, indeed, for consistency with fabric. And there are really many situations where I have AppEngine already running on port 8000. Ideally port should be auto chosen from the first that is free above 8000 if not specified explicitly.
You still have to hardcode callable name to `application`. It still would be nice to have some autodetection logic. -- anatoly t.
On 3/28/2012 7:37 AM, Masklinn wrote:
In my ignorance, this seems like a sensible request. If I understand correctly, you are not proposing to break any existing uses but to make this more useful without being overly specialized. If you file an issue, Phillip Eby would probably be asked to review. The web-sig might be the best place to thrash out details and demonstrate 'community agreement'. A patch file, preferably with a test, along with a good text explanation, usually speeds disposition of an issue. -- Terry Jan Reedy
On 2012-03-28, at 21:13 , Terry Reedy wrote:
That would be the goal yes.
If you file an issue, Phillip Eby would probably be asked to review. The web-sig might be the best place to thrash out details and demonstrate 'community agreement'. A patch file, preferably with a test, along with a good text explanation, usually speeds disposition of an issue.
So you recommend I bring this over to web-sig, ideally alongside a patchfile? Will do, thank you for the suggestion.
On Wed, Mar 28, 2012 at 2:37 PM, Masklinn <masklinn@masklinn.net> wrote:
I remember the pain of using HTTPServer, CGIHTTPServer and friends just to test a few html pages through a local browser, so I hear you. Unfortunately, bug tracker is down for the maintenance for me to search for similar reports for these libraries.
it would be nice if wsgiref.simple_server could take such a file as parameter and mount the application provided:
+2
All points valid. That was also my use case for the CGI/HTTPServers.
Since wsgiref already supports `python -mwsgiref.simple_server`, the change would be pretty simple:
Is it possible to choose a more intuitive name if it is for Python 3.3 only anyway?
To summarize: python -m wsgiref.simple_server [[wsgi_script.py] [[host] [port]]] A better way: python -m wsgiref.simple_server <wsgi_script[.py][:application]> [-h host] [-p port] But for good API it would be nice to see an overview of command line params of other WSGI servers for some kind of convention.
1. Even more awesome if any WSGI application could be tested (bootstrapped) this way. 2. Let test/"PHPInfo" serve forever and add few more tabs (pyrasite for the current Python?) -- anatoly t.
On 2012-03-28, at 15:03 , anatoly techtonik wrote:
The wsgiref module has not changed on that point in Python 3 (wsgiref.simple_server is still wsgiref.simple_server), so adding behavior would be done to the same place.
actually, python -m wsgiref.simple_server [wsgi_script [host [port]]]
<wsgi_script[.py][:application]>
I don't think that is a good idea: 1. WSGI scripts don't have to have any extension or can have no extension at all (as far as I can tell, many scripts follow mod_wsgi by using a .wsgi extension) 2. Not sure why the application name would be editable, this adds needless complexity and it does not seem supported by the most populat deployment method (mod_wsgi) 3. Finally, this changes the current behavior mounting the demo app by default, which I'd rather not do unless stdlib maintainers assert it should be done. So just [wsgi_script]
[-h host] [-p port]
I'd rather not burn help's -h for host specification. Are there really so many situations where you'd want to specify a port and leave the default host?
Well as far as I can tell, most WSGI applications which can work single-threaded would work with just that.
On Wed, Mar 28, 2012 at 4:30 PM, Masklinn <masklinn@masklinn.net> wrote:
I can't see why it can not be something like: python -m wsgiref ... Making wsgiref provide a server is an intuitive guess. Non-intuitive part is that running `wsgiref` doesn't give a hint where to find this server.
All right. Let's drop [.py]
I don't use `mod_wsgi` deployment, and can't confirm your popularity rating. I use AppEngine - it uses `app` in example: https://developers.google.com/appengine/docs/python/python27/using27#Configu... gunicorn uses `app` also: http://pypi.python.org/pypi/gunicorn `wsgiref` doesn't place any restriction on callable name, so why hardcode it to `application`. Let it do discovery itself or make the callable name explicit (you know - it's better).
Well, makes sense, but how do you know that server_example has parameters? It may be better to leave a --demo argument if somebody needs a demo.
I forgot that -h is for --help. `-H host[:port]` may be a better notation, indeed, for consistency with fabric. And there are really many situations where I have AppEngine already running on port 8000. Ideally port should be auto chosen from the first that is free above 8000 if not specified explicitly.
You still have to hardcode callable name to `application`. It still would be nice to have some autodetection logic. -- anatoly t.
On 3/28/2012 7:37 AM, Masklinn wrote:
In my ignorance, this seems like a sensible request. If I understand correctly, you are not proposing to break any existing uses but to make this more useful without being overly specialized. If you file an issue, Phillip Eby would probably be asked to review. The web-sig might be the best place to thrash out details and demonstrate 'community agreement'. A patch file, preferably with a test, along with a good text explanation, usually speeds disposition of an issue. -- Terry Jan Reedy
On 2012-03-28, at 21:13 , Terry Reedy wrote:
That would be the goal yes.
If you file an issue, Phillip Eby would probably be asked to review. The web-sig might be the best place to thrash out details and demonstrate 'community agreement'. A patch file, preferably with a test, along with a good text explanation, usually speeds disposition of an issue.
So you recommend I bring this over to web-sig, ideally alongside a patchfile? Will do, thank you for the suggestion.
participants (3)
-
anatoly techtonik -
Masklinn -
Terry Reedy