Chad Whitacre wrote: > All, > > Thanks, Jim and Ian, for bringing this discussion online. > > I have two hesitations with Paste Deploy: > > 1. The configuration syntax is really complex. I'm much more > comfortable with multiple simpler config files.
Is it really that complex? There's a few too many ways to do middleware around applications, I'm afraid. get/set is really a rather obscure feature that I seldom use. The distinction between "composite" and "app" isn't necessary, I think. The ability to inherit from sections is really useful IMHO (though not well described in documentation); that's where you do something like "use = other_section", and then add settings that override that other section's settings. > 2. I'm not clear on how Paste Deploy's abstractions map to the > filesystem. What does my website root look like? > > > With Aspen, I went with a well-defined filesystem layout (a > Unix-style userland) and multiple configuration files (in etc/), > each with their own simple syntax. > > So if you publish a blog app called SuperBlog, let's say, you > would mount it in etc/apps.conf, e.g.: > > / myapp:root > /blog superblog:main > > SuperBlog would configure itself with etc/superblog.conf, a file > with a simple syntax described in your SuperBlog documentation. > SuperBlog also has access to Aspen's global config through a > simple API. The way I have generally configured websites like this is like: [composite:main] use = egg:Paste#urlmap / = config:root.ini /blog = config:superblog.ini Then I put root.ini and superblog.ini alongside this configuration file, and each has an [app:main] section. (You can also point to another section in a file, like config:root.ini#other_section) > I suggest that a system with multiple simple config files is much > more scalable than a single complex config file syntax. Imagine > if all of Unix were configured using a single syntax! I think it depends some on the particular case. Paste Deploy lets you do both. For instance, in one case we made a really simple application that just returned a random bit of HTML selected from a specific file full of HTML snippets (used with SSIs). The basic config looked like: [app:random] use = egg:Randomizer file = /path/to/file.html Except we had about 5 of these, and we put them all in one file and then mounted them like: [composite:main] use = egg:Paste#urlmap /random1 = config:random.ini#random1 /random2 = config:random.ini#random2 ... There's other cases where having both options is nice. Because Paste Deploy doesn't fold config files together, you can also reuse them from different contexts. (A more common way to use multiple config files -- what ConfigParser.load supports -- is to just overlap all the sections, usually totally clobbering each other. I like this more explicit way of bringing in configuration, which treats configuration like a composable set of configurations instead of a system where all the configuration files are pretty tightly bound to each other.) > Also, I don't think we should underestimate the importance of the > file/executable distinction. A standard "file format" for a > website enables a wider tool ecosystem to evolve: interactive > shells, debuggers, test runners, skel systems, configuration UIs. > It also makes any given website easier to comprehend and maintain. I'm not sure about the distinction you are making here. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
