[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