[Web-SIG] more comments on Paste Deploy

[Ian Bicking]

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 | ianb at colorstudy.com | http://blog.ianbicking.org