[Web-SIG] A Python Web Application Package and Format

[Alice Bevan–McGregor]

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 
> <alice at 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.