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).
> It's not like this is Paste-specific stuff. No one knows how to > do this stuff in CherryPy. No one seems to have any authoritative > answer on how you deploy these apps -- how you move between > servers, how you change the application root, how you put apps > together into a single server. Everything is ad hoc stuff that just > barely works for one app on one server. It's all "recipes" > No one knows how to do this stuff in CherryPy
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:
Note that this process will now be officialized with the new "cherrypy.tree.mount" API in CP-2.2.
> I think these shaky underpinnings are risky for the project.
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.
r...@cherrypy.org wrote: > 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*
> 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.
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.
> All my respect applies to Ian Bicking for working hard of making > CherryPy WSGI compatible. *thumbs-up*
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.
> 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 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.
> > All my respect applies to Ian Bicking for working hard of making > > CherryPy WSGI compatible. *thumbs-up*
> 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.
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.
Armin Ronacher wrote: > 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.
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.
> Nobody has advantages of a broken WSGI Interface.
We all agree on that.
Robert Brewer System Architect Amor Ministries fuman...@amor.org
> Ok. So CherryPy has died for me. That's not only ignorance, that is the > view of one developer.
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.
> All my respect applies to Ian Bicking for working hard of making > CherryPy WSGI compatible. *thumbs-up*
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).
> [ from http://blog.ianbicking.org/my-cherrypy-rant.html]: > > It's not like this is Paste-specific stuff. No one knows how to > > do this stuff in CherryPy. No one seems to have any authoritative > > answer on how you deploy these apps -- how you move between > > servers, how you change the application root, how you put apps > > together into a single server. Everything is ad hoc stuff that just > > barely works for one app on one server. It's all "recipes"
> > No one knows how to do this stuff in CherryPy
> 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 ...
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:
>> Ok. So CherryPy has died for me. That's not only ignorance, that >> is the >> view of one developer.
> 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.
>> All my respect applies to Ian Bicking for working hard of making >> CherryPy WSGI compatible. *thumbs-up*
> 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.
______________________________________________________ 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
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:
> "Of course, all this can be done and lots of people have done it, but it's ad hoc."
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.
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.