Hey, There is a lot of terminology here that would not be understood by some random sys admin coming to have a look at the config file.
Below I pasted it here without the comments. Sometimes it is good to have a look at things without comments to see how readable they are. Is this config file reusable? Can I place it in a path of other apps, and then it could live in say /app2 instead of at / Can it not care about the server it is running on? [server:main] use: Paste wsgiutils port: 8080 host: 127.0.0.1 [application: main] use: Paste pipeline pipeline: printdebug urlmap [filter: printdebug] use: Paste printdebug [application: urlmap] use: Paste urlmap /home = fb1 /other = fb2 [application: fb1] use: FileBrowser app browse_path = /home/ianb [application: fb2] use: FileBrowser app browse_path = /home/rflosi On 7/29/05, Ian Bicking <[EMAIL PROTECTED]> wrote: > I've created a branch in Paste with a rough experiment in WSGI > deployment, declarative but (I think) more general than what's been > discussed. The branch is at: > > http://svn.pythonpaste.org/Paste/branches/wsgi-deployment-experiment/ > > All the specific modules for this stuff are in wsgi_*; wsgi_deploy.py > being the main one. > > And an application that is runnable with it is at: > > http://svn.pythonpaste.org/Paste/apps/FileBrowser/trunk/ > > It's experimental. It's far too bound to ConfigParser. Maybe it's too > closely bound to .ini files in general. It doesn't handle multiple > files or file references well at all. Actually, not just not well, but > just not at all. But I think it's fairly simple and usable as a proof > of concept. > > > And here's the deployment file, with some comments added: > > # This is a special section for the server. Probably it should > # just be named "server", but eh. This is for when you use > # paste.wsgi_deploy.make_deployment -- you can also create an > # application from this file without serving it; it just happens > # to be that you can put both application sections and a server > # section in the same file without clashing... > [server:main] > # use: does pkg_resources.load_entry_point(spec, 'type...', name) > # you can also use "factory" to avoid eggishness. > # servers have a type of wsgi.server_factory00 > # applications have a type of wsgi.app_factory00 > # filters (aka middleware) have a type of wsgi.filter_factory00 > use: Paste wsgiutils > port: 8080 > host: 127.0.0.1 > > # "main" is the application that is loaded when this file is > # loaded. > [application: main] > # This is an application factory. The application factory is passed > # app_factory(this_configparser_object, this_section), and returns > # the application. In this case the pipeline factory will use other > # sections in the config file to compose middleware. > use: Paste pipeline > # These each refer to sections; the last item is an application, the > # others are filters. > pipeline: printdebug urlmap > > # Here's that filter. > [filter: printdebug] > use: Paste printdebug > > # This isn't a filter, even though it dispatches, because it doesn't > # dispatch to a single application. > [application: urlmap] > use: Paste urlmap > # Path like things are used to map to other named applications. > # In this case nothing is mapped to /, so you'll get a 404 unless > # you go to one of these paths. But something could be mapped to /, > # of course. > /home = fb1 > /other = fb2 > > # This is the first real application. > [application: fb1] > use: FileBrowser app > > # This is a configuration parameter that is passed to the application. > # The actual passing happens in wsgi_deploy.make_paste_app, which > # is invoked by the 'app' entry point. It uses the paste convention > # of a flat configuration. > browse_path = /home/ianb > > # And the same app, but with different configuration. Of course > # the pipeline app could also be used, or whatever. Ideally it > # should be easier to point to other files, not just other sections. > [application: fb2] > use: FileBrowser app > > browse_path = /home/rflosi > > > > -- > 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/renesd%40gmail.com > _______________________________________________ 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
