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

Daniel Holth dholth at gmail.com
Mon Apr 18 23:11:21 CEST 2011


The file format discussion seems utterly pointless. Roberto de Ioris's uWSGI 
seems to make do with every file format. Would it be more useful to talk 
about what the deserialized configuration looks like in Python?

If you want the format to specify cron jobs and services and non-wsgi 
servers, why not go the whole way and use the Linux filesystem hierarchy 
standard. The entry point is an executable called `init`, configuration goes 
in /etc/, cron jobs go in /etc/cron.d etc. This should be flexible enough.

I hope most applications won't need to look at the contents of app.yaml (the 
application container config) at all. It certainly would not be generally 
useful for an application to inspect GAE's app.yaml. Whether the application 
container mucks around in the application's config is another messy issue, 
apart from the necessary 'mechanism to connect to deployment database' or 
other resources that are unique to the production environment.

Paste Deploy configures logging by passing the .ini to logging before 
invoking the app's entry point. This is the application container 
configuring the logging. For example a cool application container feature 
would be to have a little web application that manipulated logging 
configuration in a database, or reconfigured logging between requests 
without restarting the application.

One way to pass 'services' information would be to specify a support package 
with abstract base classes and have a procedure for proposing new standard 
services to the web-sig. The container would have to populate a registry of 
named implementations of those services it is able to support:

class support.databases.PostgreSQL(support.databases.SQLAlchemy): 
sqlalchemy_connection_string

support.get_default(support.databases.PostgreSQL)
support.get_named(support.databases.PostgreSQL, 'secondary')
support.get_all(support.databases.PostreSQL) -> [(PostgreSQL(), 'default'), 
(PostgreSQL(), 'secondary')]

silverlining would have to specify and register class PostgreSQL: @property 
def sqlalchemy_connection_string: return os.environ['...']


I would really like to see a basic specification with no support for 
services or 'spending an hour running apt-get to reconfigure the server 
before eventually getting around to running the application', and a 
procedure for extending the format. The goal would be only to avoid running 
'pip install -r' during deployment and pointing the WSGI runner at a 
directory instead of a specific script. In that case sandboxing or 
server/hardware abstraction concerns would be version 2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20110418/53639c9d/attachment.html>


More information about the Web-SIG mailing list