[Web-SIG] more comments on Paste Deploy

[Ian Bicking]

Chad Whitacre wrote:
>> >    2. I'm not clear on how Paste Deploy's abstractions map to the
>> >       filesystem. What does my website root look like?
>>
>> The way I have generally configured websites like this is like:
>>
>>    [composite:main]
>>    use = egg:Paste#urlmap
>>    / = config:root.ini
>>    /blog = config:superblog.ini
> 
> Right, that's the configuration, but where is "egg:Paste#urlmap" on
> the filesystem? Are the three ini files alone in some directory? Where
> is paste? Where is SuperBlog? Where is the rest of the site? I find it
> easier to start with the filesystem and then move up into
> object/config abstractions.

You just have to understand what egg:Paste#urlmap is, probably from some 
documentation.  Admittedly that's boilerplate in the eyes of most people 
who use it.  It's there explicitly because Paste Deploy doesn't build 
*any* WSGI anything into it, it only composes pieces, one of the most 
common being urlmap.  You can see docs for it with "paster points 
paste.composite_factory urlmap", though I now notice I haven't written 
any docs for it (bad of me), and that is hardly a simple command line. 
I would certainly want to build a command-line help/browser (and 
probably web one too) as part of a rewrite of the system.

The three ini files do go in the same directory, though of course you 
could do config:superblog/app.ini or something like that if you wanted 
to set it up differently.  It's a relative filename, relative to the 
file where it is given.

The applications themselves are eggs.  You install them however you want 
to install them (of course I'd strongly recommend workingenv, 
virtual-python, or zc.buildout, but that's a separate concern).  Some 
people have mentioned some frustration about having to build full 
libraries with a namespace, setup.py, eggs, etc. just to use 
applications.  But I think even pretty modest shops writing very one-off 
apps gain a real benefit from these patterns, once you get over the 
initial hump (and we can build tools to make the initial hump not so 
bad, that's the point of paster create).  Anyway, here's one reply I 
made to that request: 
http://pythonpaste.org/archives/message/20070215.192041.1534ce27.en.html

There's a lot of practices around library management that *has* to be 
done, because people use libraries.  Most of this applies pretty well to 
applications as well -- and since everyone *needs* to learn how to 
manage their libraries, using the same mechanisms for managing 
applications has some advantage.

Incidentally, one change to the config format that would make it 
possible to remove the explicit idea of "composite" apps, is to make 
some key syntax that will instantiate the named object.  E.g.,:

   app / = config:root.ini

Then the keywords passed would just be {"/": <actual WSGI app>}, instead 
of the current {"/": "config:root.ini"} (where the "config:root.ini" is 
passed to the loader object that the composite factory gets).

>> > 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.
> 
> ODT vs. DOC
> ODS vs. XLS
> ODP vs. PPT

Still unclear.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org