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

[Ian Bicking]

On Thu, Apr 14, 2011 at 2:53 AM, Graham Dumpleton <
graham.dumpleton at gmail.com> wrote:

> 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. This actually works more
> universally as it works for servers whichttps://
> bitbucket.org/ianb/silverlining/src/tip/silversupport/appconfig.py#cl-298hmap URLs to file based
> resources as well. 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. 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.
>

The main way to load applications in Silver Lining is basically like a wsgi
script; or more specifically a file that is exec'd and it looks specifically
for a variable application.  Silver Lining also supports Paste Deploy .ini
files, but in practice this doesn't seem that important (after all you can
run paste.deploy.loadapp in the script).

In this case the mapping of filenames and use of extensions doesn't matter,
as applications would not be compelled to use any particular extension, and
traversing into the application wouldn't make sense.

Another thing that is common with .wsgi files (and similarly for App Engine
script handlers) is that developers do all sorts of initialization (like
changing sys.path etc).  This makes it hard to access the application except
through that entry point, thus requiring all access to be in the form of URL
fetching (again like App Engine).  So on one hand I like the .wsgi file
technique; on the other hand I don't ;)

Most of what we're talking about is, in Silver Lining, implemented in
silversupport.appconfig.  Particular pieces:

Loading the application:

https://bitbucket.org/ianb/silverlining/src/tip/silversupport/appconfig.py#cl-310
Set up sys.path:

https://bitbucket.org/ianb/silverlining/src/tip/silversupport/appconfig.py#cl-298
Set up services:

https://bitbucket.org/ianb/silverlining/src/tip/silversupport/appconfig.py#cl-223

There's going to have to be a bit of indirection with services, as an
application is asking in effect for an interface, and each tool may
implement that interface differently (maybe a package could provide sort of
an abstract base class for these, but the specific implementation is going
to be very deployment-tool-specific).

Also generally more is setup before the .wsgi-like script is executed in
Silver Lining than in mod_wsgi.  Well, here's the actual mod_wsgi-.wsgi
script that Silver Lining uses:

https://bitbucket.org/ianb/silverlining/src/8597f52305be/silverlining/mgr-scripts/master-runner.py
But it's a bit confusing because it translates a bunch of variables set by
the rather obtuse Apache config to figure out what application to run and
how.  But sys.path is fixed up, services are "activated" (mostly meaning
they set their environmental variables), stderr/stdout is fixed up (since
there's some sense of logging in the system, I felt there was no reason to
bar use of those streams), and then some tool-specific stuff is done (e.g.,
fixing up the request URL given the Varnish setup).  These are the examples
of the kind of detailed specification of parts of the environment that I
guess we need to have -- it's really how the entire process is setup that we
need to specify, not just the WSGI request portion (which at least we don't
have to specify much since that's done).

  Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20110414/e788fa06/attachment-0001.html>