> >> > 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).
Dude, my eyes are seriously glazing over. I want you to say something simple, like: $ cd /usr/local/www $ workingenv.py example.com ... $ cd example.com $ source bin/activate (example.com)$ mkdir etc Then stick a config file in etc/ and run a simple command to start your website. That's the kind of thing I imagine you doing (eh?), and it's also the thing that Aspen does. The difference is mostly in the config files. Now, Jim: it looks like Zope still uses a Unix-y userland for INSTANCE_HOME, yes? So that's Paste, Pylons(?), Aspen, Zope2 and Zope3 all using the same filesystem layout. IINM the filesystem structures of Django and CP/TurboGears are module-level (Bob?), so they could easily fit into lib/python. If we could agree on a really simple first-line config file that handles basic process configuration--address, user/group, threads, etc.--and then points to the next layer config--be it zope.conf, paste.ini, apps.conf, or settings.py--then we'd be pretty far towards a common app server. That is to say, I think we are really discussing three increasing levels of cooperation: 1) Server benchmarks and inter-op standards (Jim) 2) Common process management library (Bob) 3) Common web app server Without discouraging the first two efforts, I'd like to champion the third. Here would be my proposal: First, we define a "website" on the filesystem as a Unix-y userland with, at minimum, the following: etc/<foo>.conf lib/python Second, we adopt a simple ini-style format for <foo>.conf, which handles low-level process config. This file would then point to a second, framework-specific configuration layer. I suggest that this isn't too far from where we each are now, nor from where our discussion has already led. It fits long-established patterns (etc, ini), and doesn't preclude cooperation on benchmarks, inter-op, or libraries. Furthermore, collaborating here would spread around what amounts to grunt work, and give Python web deployment a simple and compelling story, while in no way crippling more advanced use cases. Are you guys interested in this proposal? If so, I can write it up in more detail. chad _______________________________________________ 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