>> 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
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
