Re: Simple entry point discovery (was: A more useful command-line wsgiref.simple_server?)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: 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
<[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:
> 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 put a WSGI callable called 'application' in
its namespace.

* Or if that is too inefficient for servers to discover, it might be
done in (still retrievable using `from foo.__main__ import
application`  - though maybe this is an abuse of the purpose of 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 (e.g. what if
it runs a blocking process) then just pick a specially named Python
file. or some such.

* Or if importing things to yield the application is a concern, a text
file like 'web.txt'  which simply reads '' or even 'foo:app' to
point to the object named app inside Then the server loads
however it wants to.

If people just agreed arbitrarily on (say) "" and
"application" it would work as soon as implemented (pretty easy).

What have I missed?
Web-SIG mailing list
[hidden email]
Web SIG: