>> To do this, we use a ConfigParser-format config file named >> 'myapplication.conf' that looks like this:: >> >> [application:sample1] >> config = sample1.conf >> factory = wsgiconfig.tests.sample_components.factory1 >> >> [application:sample2] >> config = sample2.conf >> factory = wsgiconfig.tests.sample_components.factory2 >> >> [pipeline] >> apps = sample1 sample2
On another tack, I think it's important we consider how setuptools/pkg_resources fits into this. Specifically we should allow: [application:sample1] require = WSGIConfig factory = ... Since the factory might not be importable until require() is called. There's lots of other potential benefits to being able to get that information about requirements as well. Another option is if, instead of a factory (or as an alternative alongside it) we make distributions publishable themselves, like: [application:sample] egg = MyAppSuite[filebrowser] Which would require('MyAppSuite[filebrowser]'), and look in Paste.egg-info for a configuration file. The [filebrowser] portion is pkg_resource's way of defining a feature, and I figure it can also identify a specific application if one package holds multiple applications. However, that feature specification would be optional. What the configuration file in egg-info looks like, I don't know. Probably just like the original configuration file, except this time with a factory. I don't like the configuration key "egg" though. But eh, that's a detail. -- 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