[Web-SIG] More on app configuration...
ianb at colorstudy.com
Sun Aug 21 22:22:55 CEST 2005
So, I got in the first bit of working code for paste.deploy, which is a
continuation of the work I mentioned back in the thread "WSGI
deployment: an experiment":
It's still incomplete; I only just got the very first tests to pass.
The code is in http://svn.pythonpaste.org/Paste/Deploy/trunk/
But I thought I'd describe what I'm currently thinking. First, this
isn't really configuration-file-based so much as URI-based. Right now
there's only two schemes:
And I'll probably add:
(I'm not sure where protocol should really go in this case)
Plain imports don't have a explicit protocol, so they are a little
harder to handle. Eggs use entry points, which have explicit protocols.
Configuration files use section name prefixes to denote the protocol;
though since configuration files don't contain actual code, they usually
refer to something with an explicit protocol.
Right now there's only a couple protocols -- paste.app_factory1,
paste.composit_factory1, paste.filter_factory1, and paste.server_factory1.
I added "composit" for applications that bring together other
applications. This includes URL dispatchers, pipelines, and some other
things. This is like filters, which wrap a single application, but
composits get a reference back into the application loader, so they can
load applications by name. Of course anyone can load an application by
URI, so it's not strictly necessary to have a separate type. But I
think it's helpful to make explicit when an application is really just a
dispatcher, vs. a real terminal application. I can't think of a better
name than "composit", but if anyone has ideas...
I haven't decided exactly how configuration will work. Right now I've
included both global shared configuration and local configuration.
Global configuration is inherited throughout the system, and exists in
one flat namespace. Local configuration can be added in a configuration
file. Applications can explicitly pull defaults from the global
configuration, e.g. "email_errors" might be filled by
"system_admin_email". Hopefully this makes happy those who don't like a
big global pile of settings.
So a configuration section might look like:
# This section holds global configuration
system_admin_email = ianb at colorstudy.com
use = egg:MyApp#main
# or you could do:
# paste.app_factory1 = import_spec:object
# override a global setting:
set system_admin_email = webmaster at host.com
# and a local setting:
database = mysql://localhost/myapp
It uses ConfigParser, because it's dumb and the closest thing to making
no decision on configuration formats. Maybe later it can use the file
extension to denote format; I suppose if so then I should make .ini
required right now (another scheme could be added for a different
format, but that seems wrong).
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG