On Mon, Apr 2, 2012 at 12:08 AM, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > > When using CGI or FASTCGI, with a hosting system where an executable > script needs to be supplied, it is beneficial to be able to say > something like: > > #!/usr/bin/env python -m cgi2wsgi > > #!/usr/bin/env python -m fcgi2wsgi > > where the rest of the script is the just the WSGI application. > > I have implemented this for CGI as an example at: > > https://github.com/GrahamDumpleton/cgi2wsgi > > I have done it for FASTCGI using flup as well before but that isn't > available anywhere.
That's a clever trick for CGI and a great reason to +x a script, since it's so helpful to people who need to deploy against CGI for any reason, but don't want to couple to CGI in the long run. I wouldn't personally use hashbangs with wsgiref because if I can run a Python interpreter, I have equal access to excellent pure-Python servers which are - not to slight wsgiref - miles ahead (e.g. concurrent requests, easy config, reloading). And it's not unlikely that I can just deploy locally on the same server I use in production. The use case I can imagine, if stdlib acquired a good server, is that someone writes the next Jenkins and wants to let *nix users check it out real quick by just running a script. But that case is already completely handled with a __name__ == __main__ clause at the bottom, which is also portable. > You don't see such niceties for Python where a system > admin sets up that a .wsgi script file would be understood to be a > Python WSGI application with no extra magic needing to be added to it > by the user, even though not that difficult in principle. That's a very appealing idea... Is anything really necessary besides a convention for finding a single WSGI application callable in a given directory? (i.e.: to do the job of e.g. the WSGIScriptAlias directive, only inside a directory.) To flesh out how easy this could be: * could have __init__.py put a WSGI callable called 'application' in its namespace. * Or if that is too inefficient for servers to discover, it might be done in __main__.py (still retrievable using `from foo.__main__ import application` - though maybe this is an abuse of the purpose of __main__.py since we are not running a process so much as importing just to get a Python object which doesn't know if it will be run with threads, processes, greenlets, etc.) * Or if we want to avoid spuriously running __main__.py (e.g. what if it runs a blocking process) then just pick a specially named Python file. __wsgi__.py or some such. * Or if importing things to yield the application is a concern, a text file like 'web.txt' which simply reads 'foo.app' or even 'foo:app' to point to the object named app inside foo.py. Then the server loads however it wants to. If people just agreed arbitrarily on (say) "__wsgi__.py" and "application" it would work as soon as implemented (pretty easy). What have I missed? _______________________________________________ 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