[Web-SIG] WSGI: Another level of indirection

[Ian Bicking]

Phillip J. Eby wrote:
> At 11:28 PM 8/1/2005 -0500, Ian Bicking wrote:
> 
>> Maybe a way to handle this configuration is to put in another level of
>> abstraction, sad as that is.
>>
>> I'm thinking configuration files could have something like PEP 263's
>> encodings, except that it would be an indication of who knows how to
>> build the WSGI application from the file.  So it might look like:
>>
>> # -*- wsgi-build: paste.wsgi_deploy:DeploymentConfig -*-
>>
>> Which would work with the experimental stuff I mentioned before.  It
>> should also work with .ini files, Python source, and probably other
>> configuration file syntaxes.  At some point perhaps we'll come up with a
>> standard (aka default) builder, but this could remain useful despite
>> that.
> 
> 
> Now you're *really* scaring me.  Honestly, there's no difference between 
> this proposal and saying that we'll use "#!" lines to operationally 
> determine the format by specifying an interpreter for it.  There's 
> really no *abstraction* taking place here.

Well, #! is constrained to executable paths, unlike the comment.  But if 
it wasn't, sure this is just like that... but I don't see the problem 
(or the reason for such shock ;).  Deep down #! is a good feature for 
executables, and this is just the analog.

The API would go:

app = load_wsgi_app_from_file('foo.ini')

def load_wsgi_app_from_file(filename):
     f = open(filename)
     for line in f:
         if not line.strip(): continue
         assert line.startswith('#'), "No interpreter found"
         if '-*-' in line:
             interp_spec = line.split('-*-')[1].strip()
             break
     if ' ' in interp_spec:
         interp = pkg_resources.load_entry_point(interp_spec.split()[0],
             'wsgi.config_interpreter', interp_spec.split()[1])
     else:
         interp = pkg_resources.parse('x='+interp_spec).load(False)
     f.close()
     return interp(filename)


>>   It also means I can go forward with this right now and still be
>> future compatible.
> 
> 
> I can understand the desire, but I think it would be a bad idea to give 
> this any kind of official standing or allow it to warp the process of 
> getting to a workable deployment standard.  Better for you to develop 
> your format(s) and try to make them that convinces everyone they're 
> worth standardizing on, knowing that if you fail, your format will be a 
> dead end.  :)  That should provide you with extra motivation to make it 
> a really good format for the rest of us.  ;)

I bring this up because I'm not sure there is a One Best Way for the 
deployment.  This is also something I can apply to the deployment 
configuration I already have in Paste (not the experimental stuff, but 
the configuration files in Paste).  I think other legacy systems (and 
*every* current framework has something like this) can very possibly be 
handled the same way, requiring only the addition of one comment line to 
current configurations.  This also leaves the possibility of flattening 
the configuration some without trying to jam incompatible features in.

And load_wsgi_app_from_file, under whatever name, is a function that 
needs to exist in any spec.  Standardizing it first doesn't seem that 
strange to me.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org