This is an answer to http://www.cherrypy.org/ticket/444 and
http://blog.ianbicking.org/my-cherrypy-rant.html

CherryPy was created a long time before WSGI came along. WSGI support
for CherryPy was only added later on and it's probably not perfect
right now because CherryPy was not designed with WSGI in mind.
We will try to address these issues in CP3 but right now, we don't want
to spend too much time on this in CP2 ... Why ? Because we've all got
limited time to work on CherryPy and it all comes down to priorities
...
And right now I'm more interested in fixing the security flaw in the
static filter (done), the sessiondeadlock bug (done) and shipping
CP-2.2 (beta version coming soon) rather than changing CP to make it
100% WSGI compatible. I think that these fixes and shipping CP-2.2 add
much more value.
As you've probably guessed by now I'm not a big WSGI fan because it
doesn't allow us to do anything useful that wasn't possible before and
it doesn't help solving the real life cases (more details below).

Which leads me to:

[ from http://blog.ianbicking.org/my-cherrypy-rant.html]:

Well, I've been developing, deploying and maintaining CP apps for
several years now. I've got apps using various python and CP versions,
I've got sites mixing CP and PHP apps, I've got a CP app load-balanced
on 4 servers and I regularly push new versions of the app to these
servers. And all of this doesn't seem all that hard to me and I don't
need paste or WSGI to do it ...

For instance, for deploying my app on 4 load-balanced servers and
pushing new versions regularly, I just check out the SVN tree
containing the source code of the app to each server. When I want to
push a new version to production I just run "svn update" on each of the
server (I've got a 4-line script that does the "svn update" on each
server for me). Can Paste make this process easier ? I doubt it ...
This is just one way of deploying an app ... I've also been in the
situation where we needed a more formal process (with official releases
of the app) because the app was shipped to customers ... It happened to
be on Windows so we were putting python, CP and the app in one .exe
(using py2exe) and packaging everything in an installer with InnoSetup.
The installer was just installing the app as a Windows service and it
worked great. Again, all it took was a script to do all of that and I
don't think that WSGI and Paste would have helped.

For mixing multiple apps in one website, the method I use is Apache and
mod_rewrite ... WSGI and Paste can help me mix, say, a CP app and a
Twisted app in one website but in practice, I'm much more likely to mix
a CP app with a PHP app (PHPBB for instance) and in that case, WSGI and
Paste can't help ... I'm a big fan of Apache (or lighttpd) in front of
CherryPy with mod_rewrite ... You really get the best of both worlds
and Apache is probably faster and more powerful (you can use all the
mod_xxx modules, starting with mod_ssl) than any WSGI server will ever
be.

For running multiple instances of the same app, all I do is run "python
app.py -c xxx.cfg" multiple times. I just need one copy of "app.py" and
I just have one config file per instance I want to run ...

For "mounting" multiple instances of one app within one CP server, the
simple method I've been using so far is this: the constructor of the
app takes as a parameter the path where it is mounted ("mount_path").
Whenever it generates an absolute URL is prefixes it with "mount_path".
Doesn't seem that hard to me:

class Blog:
    def __init__(self, mount_path):
        self.mount_path = mount_path
    def index(self):
        return 'blah blah ... <a href="%s/foo">foo</a>' %
self.mount_path
    def foo(self):
        ....

cherrypy.root.blog1 = Blog1('/blog1')
cherrypy.root.blog2 = Blog1('/blog2')

Note that this process will now be officialized with the new
"cherrypy.tree.mount" API in CP-2.2.

Well, I don't share your negative view on this and I'd rather have a
more positive approach and look at what makes CP so great.
CP is easy, lightweight and has a very pythonic API. That's why people
like it and write web apps with it and they don't need WSGI or Paste to
do it.

So, in short:
 - I'm not going to spend too much time on WSGI and Paste myself
because I don't really believe in it and I've got more useful changes
to make to CherryPy.
 - Having said that, I acknowledge the fact that some people might see
some added value in WSGI and Paste ... this is open-source ... everyone
has some features that they're personnally interested in ... submit
patches for your pet features and we'll include them.

Remi.

Ok. So CherryPy has died for me. That's not only ignorance, that is the
view of one developer. And WSGI is defined in a PEP and should work for
CP also. Nobody has advantages of a broken WSGI Interface.

All my respect applies to Ian Bicking for working hard of making
CherryPy WSGI compatible. *thumbs-up*

Hi Armin,

I am sorry to hear that.

You are right but interesingly I wonder if there so many web frameworks that
actually support entirely correctly WSGI. If they exist, then great :)

BTW, there is hardly one HTTP server outthere that does respect entirely HTTP
RFCs but the web hasn't crashed yet. So although I agree we should (we must)
have a better WSGI support (I like standards) let's not shoot down CherryPy
because of that.

I think you should thank Robert instead since he is the one who has made
CherryPy what it is now. He has brought support to WSGI long before Ian tried.
I am happy Ian revealed some flaws we hadn't thought so far but again we have
agreed on bringing a better support in CherryPy 3.

- Sylvain

Hi Sylvain,
I for my self like WSGI. My applications run von FastCGI, CGI,
mod_python and other
interfaces and I don't have to think about interface specific features,
the Wrapper
handles that for me.
And WSGI (especially paste) will be the only way to let hosters support
python on
a webspace. Nobody would allow a user the edit the apache config.

Maybe I will then CherryPy works together with WSGI. But for now I will
use my own
wrapper for the next webapplications and django for my community page.

Regards,
Armin

Simply saying, "WSGI is defined," isn't enough. Ian is not the final
authority on interpreting that spec, and it is my assertion that Ian's
interpretation of the WSGI spec is incorrect. Here's what I believe his
assertion is (corrections by Ian most welcome):

Given:
    SCRIPT_NAME: The initial portion of the request URL's
    "path" that corresponds to the application object,
    so that the application knows its virtual "location".

The phrase "so that ... knows" means that the application side MUST NOT
otherwise know its virtual "location"; it MUST only obtain that
information from the value of SCRIPT_NAME.

My assertion is:

The phrase "so that ... knows" means "so that the application MAY know".

Some "applications" may be that stupid; lots of CGI scripts were written
that way (and then each rolled their own hacks to get around IIS' or
Apache's quirks). CherryPy, however, is more self-aware than that, and
expects the deployer to tell CherryPy the virtual "location" of apps on
server start. Support for accurate SCRIPT_NAME values in current WSGI
servers and gateways continues to be spotty and untrustable; CherryPy
avoids that issue by being more aware.

I am the first to admit that "telling CherryPy the location of your app
on server start" is not as flexible as it could be in CP 2.1. We are
working on a much-improved API for 2.2. But that is an entirely separate
issue and has nothing to do with CP's WSGI support.

We all agree on that.

Robert Brewer
System Architect
Amor Ministries
fuman...@amor.org

Yes, that is my view and I have the right to express it :)
I think that WSGI adds almost no value. If the goal is to be able to
deploy a CherryPy application under FastCgi or CGI (for practical
hosting purposes) then it's much easier to just write a small custom
wrapper for CherryPy. This is pretty easy and Quixote had it way before
WSGI came along.
I think that WSGI just adds another layer that complicates things,
confuses people and brings very little benefit for real life cases.

But I do realize that this is only my view and CP is not a one-man
project ... This is why we'll try to improve our WSGI support in CP-3.

I respect Ian for his work but I disagree with the message that he's
been spreading lately on various blogs and forums.
I get the feeling that he's spreading the following message (Ian,
please correct me if that is not the message that you're spreading):

a- Deploying a CP app is hard
b- Paste is the answer and therefore people should use Paste.

I disagree with both. I don't think that deploying a CP app is hard at
all (I've explained some of the techniques I use in my previous post).
And I don't think that people need Paste. It just complicates things,
adds another layer, another dependency and confuses people. In some
limited cases it might be useful but for most real life cases I think
it doesn't help at all (again, I've explained in my previous post why
in most cases Apache (or lighttpd) is the answer, not Paste).

Remi.

It is my perception that it *is* hard for most people, and that there's
no clear and consistent way to handle this sort of thing.  Of course
you can figure this stuff out, because you have a fairly complete and
internalized view of how CherryPy works from the inside and you
understand the problems you encounter, but it's not clear to other
people, and from what I can tell any such deployment depends on several
pieces being configured in tandem with confusing failure cases and lots
of potentials for subtle bugs in deployment.

Maybe a more explicit critique: there is no single, consistent story
for how someone should lay out and write a CherryPy application and
deploy it in multiple environments (obviously at least devel and
production), under different base paths (e.g., / in devel with custom
HTTP server, and /myapp in production under Apache), and how to manage
a set of such applications that form a typical website.

Of course, all this can be done and lots of people have done it, but
it's ad hoc.  Many of the recipes bouncing around are broken
(VirtualPathFilter on the wiki is broken, for instance).  The solution
isn't to fix the recipes; this should be core functionality.

When tree.mount was discussed on IRC, I asked that people step back and
consider how people were supposed to use this.  But no one replied or
reacted to that at all.  That feature isn't being *designed* the right
way.  Figure out how people are should ideally use CherryPy for the
variety of likely use cases.  Then make that work.  Instead these
deployment issues are being designed backwards, starting from the
object publisher and then just hoping that people will figure out how
to use those functions in their applications.  If I understood how
people were going to use tree.mount, for instance, I could possibly
implement another version of Tree that does what I want.  But since I
have no idea what is expected, I have no idea when or how that is going
to be called, and I can't reliably do anything with that API.

But, back to the concrete, you say you want CP3 to address some of
these issues.  So what will CP3 look like?

Also, I hope you'll understand my rant for what it is -- an emotional
response to frustration I felt after struggling with the code (which is
why I called it a rant).  If it pisses y'all off and you go off saying
"I'll show him", then okay.  So show me.  If I just steamed in private,
dismissed CP in private conversations, dismissed the projects that
build on CP, I don't think that would be much better.  But if you don't
think my criticism is based on anything, and you plan to simply ignore
it, then I suppose it serves no purpose to say it publically.  Except
perhaps to make it clear to people who are interested in Paste that CP2
isn't a good choice (which I am saying here because that's basically
what you are saying).

Also note that I wouldn't have any opinion on any of this if I wasn't
trying to reach out to you guys, making a genuine effort to support CP
as a whole in Paste.

I agree with Remi that WSGI complicates things while adding little  
value.  CherryPy is so great for me because it is so simple to  
understand.  It does just one thing--pass HTTP requests to methods  
and returns back HTML.  All the other stuff that Django and  
TurboGears adds on is good if you need it, but if you don't, then you  
pay the price of a larger learning curve.  I haven't looked into  
Paste, but it sounds like it is for a situation where you have a  
bunch of web apps that you want to work together.  That's not what  
CherryPy is about--CherryPy is about making the smallest simplest web  
app.  And because it does that so well, it's the foundation of these  
other projects.  That's exactly right--keep CherryPy simple, and then  
build other projects around it for more specialized situations.

As far as deploying, CherryPy was much simpler to deploy than Webware.

-winston

On Jan 23, 2006, at 2:04 PM, r...@cherrypy.org wrote:

______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

My feelings are similar.

That is to say that I feel little enthusiasm towards all this talk
about 'proper' WSGI support and/or Paste. I just don't think that it is
possible to have a solution that is both generic and simple ... in
practice things just do not work that way ...

For me cherrypy is about "invisibility", it completely stays out of the
way. It is already such an amazingly simple and straightforward
approach that all these 'generalizations' appear to be solutions to
problems that do not actually exist.

To address a sentence in a post above:

I would not be so quick to equate 'ad-hoc' with 'bad' . Practicality
beats purity, simplicity beats standardization. I'd rather do whatever
needs to be done in  few lines within a simple framework rather than
through yet another abstract and layer introducing yet another set of
limitations.

i.

If one thinks about WSGI being only apps, then the obvious conclusion is
"CP already does this".

Sure Remi fixing filters (BTW thank you Remi) was top priority from his
point of view, which is CP developer's one.

But the whole point IMHO of WSGI is **middleware** . May be there
wouldn't have been needed fixes in the first place if filters (static,
session, auth, etc) were pulled from a central repository (setuptools
eggs, PasteDeploy) where they would be developed/fixed once for all, as
shared components between frameworks.

One of the few Python drawbacks is that such a powerful and expressive
language makes it easy (compared to say C or even Java/C#) to ever
rewrite stuff. So we get CP sessions, flup sessions, XYZ sessions, etc.

"Apache load balancing amongst multiple hosts" and "multiple CP
processes per host" are all great stuff, but that's orthogonal to the
"multiple apps per process" and "apps being agnostic about their actual
location/mount point" issues.

Saying "I want my very own filters for my framework" is like saying "I
want my own mod_cache/rewrite/ssl"... Sure you can do it, but is this
the best possible decision ?

So I disagree about "WSGI brings nothing". May be nothing completely
new, but smarter and much more open design for sure.

A legitimate point of worrying is overhead. I'm not sure of anything
here, but I don't see any reason for the WSGI adapter being that bad
against say SCGI or FCGI or mod_python. May be some tests (e.g. ab2
stats about CP+CherryPaste vs. genuine CP) would enlighten this...

Another one is "WSGI is sometimes ambiguous". Right... but I don't think
that's a blocker... Often RFC's are very very open about "important"
stuff, but the web is functional today.

The IRC log show that most of the issues are well-known (and that smart
people do not get angry even when strongly disagreeing on some
"important" subject), so

Sure this is all free software... so Remi (and from what I understand
Robert, Sylvain and the other devs) have all rights to say "not for me"
or "not before CP3".

Most projects where feedback of the majority of end-users is blindly
ignored by developers are doomed.

I'm still wondering about what percentage of CP users do want/need WSGI,
and I'm very interested in other users feedback...

I've been great CP fan, and I almost instantly dropped Webware when I
discovered CP. Now I'm looking about Pylons+Mighty because of the Paste
issue, even at the cost of learning another (perlish ;-) templating
language...

This is too bad, when compared to other projects...

e.g. TurboGears & templates:

At start the official point of view was "Kid templating is the best,
don't tell us about the other packages"...

Then open-minded people did understand that whatever the reason, other
guys may hate XML stuff, or simply have tons of existing templates.

So Christian Wyglendowski and Cliff Wells designed a Template Plugin
engine and spec, moreover a framework agnostic one.

And K.Dangoor did accept to push it in TG even if he's still a great
defender or Kid.

And B.Bangert integrated Buffet support in Pylons for guys that don't
want to depend of Myghty only.

That's free software, too ;-)

I can admit that WSGI/Paste support will not show up before CP3... Then
let's hope CP3 is not that far.

signature.asc < 1K Download