So maybe here's a deployment spec we can start with. It looks like: [feature1] someapplication.somemodule.some_function
[feature2] someapplication.somemodule.some_function2 You can't get dumber than that! There should also be a "no-feature" section; maybe one without a section identifier, or some special section identifier. It goes in the .egg-info directory. This way elsewhere you can say: application = SomeApplication[feature1] And it's quite unambiguous. Note that there is *no* "configuration" in the egg-info file, because you can't put any configuration related to a deployment in an .egg-info directory, because it's not specific to any deployment. Obviously we still need a way to get configuration in there, but lets say that's a different matter. This puts complex middleware construction into the function that is referenced. This function might be, in turn, an import from a framework. Or it might be some complex setup specific to the application. Whatever. The API would look like: wsgiapp = wsgiref.get_egg_application('SomeApplication[feature1]') Which ultimately resolves to: wsgiapp = some_function() get_egg_application could also take a pkg_resources.Distribution object. Open issues? Yep, there's a bunch. This requires the rest of the configuration to be done quite lazily. But I can fit this into source control; it is about *all* I can fit into source control (I can't have any filenames, I can't have any installation-specific pipelines, I can't have any other apps), but it is also enough that the deployment-specific parts can avoid many complexities of pipelining and factories and all that -- presumably the factory functions handle that. I don't think this is useful without the other pieces (both in front of this configuration file and behind it) but maybe we can think about what those other pieces could look like. I'm particularly open to suggestions that some_function() take some arguments, but I don't know what arguments. -- 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