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 | [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