BTW, a simple example that includes proposed solutions for all of these
requirements would go a long way towards helping me (and maybe others)
understand how all the pieces fit together. Maybe something like:
- Define two simple WSGI components: a WSGI middleware and a WSGI
application.
- Des
Thanks...
I'm still confused about high level requirements so please try to be
patient with me as I try get back on track.
These are the requirements as I understand them:
1. We want to be able to distribute WSGI applications and middleware
(presumably in a format supported by setuptools).
Phillip J. Eby wrote:
>> Another option is we pass in a single dictionary that represents the
>> entire configuration. This leaves room to add more arguments later,
>> where if we use keyword arguments for configuration then there's really
>> no room at all (the entire signature of the factory is
At 09:33 PM 7/24/2005 -0500, Ian Bicking wrote:
>We could go free-form, and you call application factories with keyword
>arguments that are dependent on the application. This serves as
>configuration. You can call filter factories with keyword arguments,
>and one special (required?) keyword argum
At 08:49 PM 7/24/2005 -0500, Ian Bicking wrote:
>Chris McDonough wrote:
>>Sorry, I think I may have lost track of where we were going wrt the
>>deployment spec. Specifically, I don't know how we got to using eggs
>>(which I'd really like to, BTW, they're awesome conceptually!) from
>>where we were
OK, so lets assume we have a way (entry points) to get an object that
represents the package's WSGI application, as a factory. What do we do
with that factory? That is, how do we make an application out of the
factory? Well, it seems rather obvious that we call the factory, so
what do we pas
At 08:35 PM 7/24/2005 -0400, Chris McDonough wrote:
>Sorry, I think I may have lost track of where we were going wrt the
>deployment spec. Specifically, I don't know how we got to using eggs
>(which I'd really like to, BTW, they're awesome conceptually!) from
>where we were in the discussion about
Phillip J. Eby wrote:
>> Like for a package that distributes only one application. Or these
>> just different spellings for the same thing?
>
>
> I don't understand you. The most minimal way to specify a single entry
> point in setup() is with:
>
> entry_points = """
> [groupna
At 07:26 PM 7/24/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>The actual syntax I'm going to end up with is:
>> entry_points = {
>> "wsgi.app_factories": [
>> "feature1 = somemodule:somefunction",
>> "feature2 = another.module:SomeClass [extra1
Chris McDonough wrote:
> Sorry, I think I may have lost track of where we were going wrt the
> deployment spec. Specifically, I don't know how we got to using eggs
> (which I'd really like to, BTW, they're awesome conceptually!) from
> where we were in the discussion about configuring a WSGI pipel
Sorry, I think I may have lost track of where we were going wrt the
deployment spec. Specifically, I don't know how we got to using eggs
(which I'd really like to, BTW, they're awesome conceptually!) from
where we were in the discussion about configuring a WSGI pipeline. What
is a "feature"? Wha
Phillip J. Eby wrote:
> The actual syntax I'm going to end up with is:
>
> entry_points = {
> "wsgi.app_factories": [
> "feature1 = somemodule:somefunction",
> "feature2 = another.module:SomeClass [extra1,extra2]",
> ]
> }
That seems wei
At 02:12 PM 7/24/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>However, after more thought, I think that the "next application" argument
>>should be a keyword argument too, like 'wsgi_next' or some such. This
>>would allow a factory to have required arguments in its signature, e.g.:
>>
At 02:12 PM 7/24/2005 -0500, Ian Bicking wrote:
>This kind of addresses the issue where the module structure of a package
>becomes an often unintentional part of its external interface. It feels a
>little crude in that respect... but maybe not. Is it worse to do:
>
> from package.module impor
Phillip J. Eby wrote:
>> It goes in the .egg-info directory. This way elsewhere you can say:
>>
>>application = SomeApplication[feature1]
>
>
> I like this a lot, although for a different purpose than the format
> Chris and I were talking about.
Yes, this proposal really just simplifies
Did I say scarecrow? Man it must have been late, I think I meant
strawman ;)
--
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:
[cc:ed to distutils-sig because much of the below is about a new egg
feature; follow-ups about the web stuff should stay on web-sig]
At 04:04 AM 7/24/2005 -0500, Ian Bicking wrote:
>So maybe here's a deployment spec we can start with. It looks like:
>
>[feature1]
>someapplication.somemod
At 04:05 AM 7/24/2005 -0400, Chris McDonough wrote:
>- OR (if we passed the factory a namespace instead of a filename) -
>
> [foo.factory]
> arbitrarykey1 = arbitraryvalue1
> arbitrarykey2 = arbitraryvalue2
>
> [bar.factory]
> arbitrarykey1 = arbitraryvalue1
> arbitrarykey2 = arbitraryv
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 ide
Thanks for the response... I'm not going to respond point-by-point here
because probably nobody has time to read this stuff anyway.
But in general:
1) I'm for creating a simple deployment spec that allows you to define
static pipelines declaratively. The decision middleware thing is just
an idea
On Sat, 2005-07-23 at 21:57 -0400, Phillip J. Eby wrote:
> > > For that matter, if you did that, you could specify the above as:
> > >
> > > [blaz.factory]
> > > config=blaz.conf
> > >
> > > [bleeb.factory]
> > > config=bleeb.conf
> >
> >Guess that would work for me, but out of
21 matches
Mail list logo
