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).
Actually, let me give this a shot.
We package up an egg called helloworld.egg. It happens to contain
something that can be used as a WSGI component. Let's say it's a WSGI
application that always returns 'Hello World'. And let's say it also
contains middleware that lowercases anything that
At 03:02 AM 7/25/2005 -0400, Chris McDonough wrote:
Actually, let me give this a shot.
We package up an egg called helloworld.egg. It happens to contain
something that can be used as a WSGI component. Let's say it's a WSGI
application that always returns 'Hello World'. And let's say it also
Great. Given that, I've created the beginnings of a more formal
specification:
WSGI Deployment Specification
-
I use the term WSGI component in here as shorthand to indicate all
types of WSGI implementations (application, middleware).
The primary deployment
At 01:35 PM 7/25/2005 -0400, Phillip J. Eby wrote:
heading ::= '[' qname trailer ']' NEWLINE
Oops. That should've been trailer?, since the trailer is optional.
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG:
Phillip J. Eby wrote:
At 12:59 PM 7/25/2005 -0400, Chris McDonough wrote:
In order to define a pipeline, we use a .ini-format configuration
Ultimately I think the spec will need a formal description of what that
means exactly, including such issues as a PEP 263-style encoding
Hi All,
I'm a bit late coming to all this and didn't really see the benefits of
the new format over what we already do so I set out to contrast new and
old to demonstrate why it wasn't *that* useful. I've since changed my
mind and think it is great but here is the contrasting I did anyway. I'd
At 10:54 PM 7/25/2005 +0100, James Gardner wrote:
The new way is like this (correct me if I'm wrong)
The modules have egg_info files like this respectively defining the
entry points:
wsgiFilters.egg:
[wsgi.middleware]
gzipper = GZip:GZip
Almost; this one should be:
[wsgi.middleware]
[cc:'d to distutils-sig because this is mostly about cool uses for the new
EntryPoint facility of setuptools/pkg_resources]
At 12:01 AM 7/26/2005 +0100, James Gardner wrote:
Hi Phillip,
There's one other advantage: this format will hopefully become as
successful as WSGI itself in adoption by
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 a part of
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 import
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.:
def
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 weird to put the
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 =
[groupname.here]
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 in the
15 matches
Mail list logo
