[Web-SIG] Scarecrow deployment config
Ian Bicking
ianb at colorstudy.com
Sun Jul 24 11:04:43 CEST 2005
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 / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG
mailing list