Howdy!
I suspect you're thinking a little too low-level.
On 2011-04-14 00:53:09 -0700, Graham Dumpleton said:
On 14 April 2011 16:57, Alice Bevan–McGregor
<al...@gothcandy.com> wrote:
3. Define how to get the WSGI app. This is WSGI specific, but (1) is
*not* WSGI specific (it's only Python specific, and would apply well to
other platforms)
I could imagine there would be multiple "application types":
:: WSGI application. Define a package dot-notation entry point to a
WSGI application factory.
Why can't it be a path to a WSGI script file?
No reason it couldn't be.
app.type = wsgi
app.target = /myapp.wsgi:application
(Paths relative to the folder the application is installed into, and
dots after a slash are filename parts, not module separators.)
But then, how do you configure it? Using a factory (which is passed
the from-appserver configuration) makes a lot of sense.
This actually works more universally as it works for servers which map
URLs to file based
resources as well.
First, .wsgi files (after a few quick Google searches) are only used by
mod_wsgi. I wouldn't call that "universal", unless you can point out
the other major web servers that support that format.
You'll have to describe the "map URLs to file based resources" issue,
since every web server I've ever encountered (Apache, Nginx, Lighttpd,
etc.) works that way. Only if someone is willing to get really hokey
with the system described thus far would any application-scope web
servers be running.
Also allows alternate extensions than .py and also allows basename of
file name to be arbitrarily named, both of which help with those same
servers which map URLs to file base resources.
Again, you'll have to elaborate or at least point to some existing
documentation on this.
I've never encountered a problem with that, nor do any of my scripts
end in .py.
It also allows same name WSGI script file to exist in multiple
locations managed by same server without having to create an
overarching package structure with __init__.py files everywhere.
Packages aren't a bad thing. In fact, as described so far, a top level
package is required.
For WSGI servers which currently require a dotted path, eg gunicorn:
See my note above; choice of Python-level HTTP interface is not up to
the application, though by all means there should be some simple way to
"launch" a development server.
The WSGI script file then can itself even be responsible for further
setup of sys.path as appropriate and so be more self contained and not
dependent on an external launch system.
The -point- (AFIK/IMHO) is to be dependent on an external launch system.
and in the end of myapp.py add bolier plate like:
from wsgiref.simple_server import make_server
httpd = make_server('', 8000, application)
print "Serving on port 8000..."
httpd.serve_forever()
Again, I've never described anything that would require that nonsense.
WSGI callable, preferably a factory callable, that's it.
Use a different server which required such boilerplate and you had to
change it.
Not the problem of the application.
Using a WSGI script file as the lowest common denominator, it would
also be nice to be able to do something like:
python -m gunicorn.server myapp.wsgi
python -m wsgiref.server myapp.wsgi
Not a half bad idea, but again, no reason to restrict it to .wsgi
files. (That's also a completely different problem then an
"applicaiton format" currently under discussion.)
I've written and rewritten my dot-colon-notation system enough that it
supports:
:: /path[/sub[...]][:object[.property]] (even if it has to execfile it)
:: package[.module[...]][/folder[...]][:object[.property]]
I think that syntax pretty much covers everything, including .wsgi
files (/path/to/foo.wsgi:application). The implementation of the above
is fully unit tested, and I really don't mind people stealing it. ;)
— Alice.
_______________________________________________
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
