Re: Simple entry point discovery (was: A more useful command-line wsgiref.simple_server?)
On Mon, Apr 2, 2012 at 12:08 AM, Graham Dumpleton
<[hidden email]> 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
(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
* 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).