[Web-SIG] Simple entry point discovery (was: A more useful command-line wsgiref.simple_server?)

[Sasha Hart]

On Mon, Apr 2, 2012 at 12:08 AM, Graham Dumpleton
<graham.dumpleton at 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?