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 = [EMAIL PROTECTED] [app:main] use = egg:MyApp#main # or you could do: # paste.app_factory1 = import_spec:object # override a global setting: set system_admin_email = [EMAIL PROTECTED] # 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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list [EMAIL PROTECTED] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
