[Web-SIG] More on app configuration...

[Ian Bicking]

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": 
http://mail.python.org/pipermail/web-sig/2005-July/001598.html

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:

   egg:EggSpec#entry_point_name
   config:config_filename#section_name

And I'll probably add:

   python:[protocol/]import_path
     (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:

   [DEFAULT]
   # This section holds global configuration
   system_admin_email = ianb at colorstudy.com

   [app:main]
   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