Re: response status when form validation fails
On Tue, 2008-08-19 at 11:43 +0200, Lawrence Oluyede wrote: I disagree. TCP is the transport protocol (which resides at the transport level of the stack). HTTP is an application protocol (which resides on top of the stack), and I'm pretty sure that the creators of HTTP intended to use 400 BAD REQUEST also for such cases. As the spec says: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. The malformed syntax they refer to is the HTTP protocol syntax (for example, malformed, missing, or improperly escaped HTTP headers, URLs, etc). The key phrase here is the request could not be understood by the server. If a form is missing a field, your server still understood (and could process) the request, it's your application that refuses the request because of its own requirements that are completely separate from the requirements of the HTTP server. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: response status when form validation fails
On Fri, 2008-08-22 at 18:43 -0700, Jonathan Vanasco wrote: question though -- what if the @validate received the right params, but there was a db error or some other server error. does that become another 4xxx code in your system, or are they all lumped into the same concept. how are those instances translated into the @validate decorator? Well, much of this problem is due to the same problem so much of the web has in general: all-around bad planning and poor specifications. It does seem rather inconsistent that a form shouldn't return a 40x but an internal server error returns a 50x. At the end of the day, I suppose it might be acceptable to return a 40x if you consider POST data as part of the request (at the same level as GET arguments are). So for instance it seems valid that: http://domain.com?page=bar returns a 40x and so a POST to http://domain.com with a body of page=bar should too. And once you accept that, it seems reasonable to include any invalid POST data as a 40x as well. Shrug. I reserve the right to reverse my position again after I've had another beer. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best practices for static resources
On Tue, 2008-06-17 at 19:55 -0700, Shannon -jj Behrens wrote:
On Mon, Jun 16, 2008 at 2:37 PM, Cliff Wells [EMAIL PROTECTED] wrote:
On Mon, 2008-06-16 at 14:26 -0700, Cliff Wells wrote:
On Mon, 2008-06-16 at 13:03 +0200, Wichert Akkerman wrote:
I am trying to figure out what the best practices for dealing with
static resources such as CSS, Javascript and images are. With a
default pylons setup every request goes through two StaticURLParser
instances and files returned by them do not get any caching headers.
This is very practical for development but not ideal for a deployment
For a deployment it would be nice to be able to serve static resources
from apache or nginx.
How do others do that? Do you use url_for to generate a URL for those
static resources and have that return a non-paster/pylons URL for
deployment environments and use the StaticURLParsers when running in
in development mode? If so, how did you set that up?
I usually just setup Nginx to handle whatever location my static content
is at. It doesn't matter if Routes is setup to handle that location as
the request never reaches Pylons.
Here's an example:
server {
server_name *.domain.com;
listen 1.2.3.4:80;
location /public/ {
root/var/www/myapp;
expires 30d;
}
location / {
proxy_pass http://127.0.0.1:8000$request_uri;
include/etc/nginx/proxy.conf; # common settings for proxying
}
}
In this case, any request for, say /public/css/style.css would map to
/var/www/myapp/public/css/style.css.
Regards,
Cliff
I let Nginx handle the URL if such a file exists. Otherwise, I let
Pylons have a shot at it:
...
server {
listen 80;
server_name localhost;
location / {
# Let Nginx handle static content, but proxy to paster for all the
# dynamic content.
root/.../wwwaiter/wwwaiter/public;
if (!-e $request_filename) {
proxy_pass http://127.0.0.1:5000;
}
}
That way I don't have to include public in my URLs ;-)
(Of course, including public in the URL would probably make life
easier if I needed to move to something more complicated like a CDN.)
Actually, I tend to use the regex style Jonathon mentioned, but I wanted
the example to be as simple as possible so the solution to the OP's
question would stand out.
Cliff
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: best practices for static resources
On Tue, 2008-06-17 at 10:36 +0200, Wichert Akkerman wrote: Previously Cliff Wells wrote: I usually just setup Nginx to handle whatever location my static content is at. It doesn't matter if Routes is setup to handle that location as the request never reaches Pylons. How do you do that during development? Do you hardcode /public/ paths for static resources everywhere? Actually, I never use webhelpers. I generally use hardcoded paths in my template and map them in the webserver, but don't see what the issue would be when using webhelpers. I don't see the whole process as being very complicated (nor any need to make it complicated). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best practices for static resources
On Mon, 2008-06-16 at 13:03 +0200, Wichert Akkerman wrote: I am trying to figure out what the best practices for dealing with static resources such as CSS, Javascript and images are. With a default pylons setup every request goes through two StaticURLParser instances and files returned by them do not get any caching headers. This is very practical for development but not ideal for a deployment For a deployment it would be nice to be able to serve static resources from apache or nginx. How do others do that? Do you use url_for to generate a URL for those static resources and have that return a non-paster/pylons URL for deployment environments and use the StaticURLParsers when running in in development mode? If so, how did you set that up? I usually just setup Nginx to handle whatever location my static content is at. It doesn't matter if Routes is setup to handle that location as the request never reaches Pylons. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best practices for static resources
On Mon, 2008-06-16 at 14:26 -0700, Cliff Wells wrote:
On Mon, 2008-06-16 at 13:03 +0200, Wichert Akkerman wrote:
I am trying to figure out what the best practices for dealing with
static resources such as CSS, Javascript and images are. With a
default pylons setup every request goes through two StaticURLParser
instances and files returned by them do not get any caching headers.
This is very practical for development but not ideal for a deployment
For a deployment it would be nice to be able to serve static resources
from apache or nginx.
How do others do that? Do you use url_for to generate a URL for those
static resources and have that return a non-paster/pylons URL for
deployment environments and use the StaticURLParsers when running in
in development mode? If so, how did you set that up?
I usually just setup Nginx to handle whatever location my static content
is at. It doesn't matter if Routes is setup to handle that location as
the request never reaches Pylons.
Here's an example:
server {
server_name *.domain.com;
listen 1.2.3.4:80;
location /public/ {
root/var/www/myapp;
expires 30d;
}
location / {
proxy_pass http://127.0.0.1:8000$request_uri;
include/etc/nginx/proxy.conf; # common settings for proxying
}
}
In this case, any request for, say /public/css/style.css would map to
/var/www/myapp/public/css/style.css.
Regards,
Cliff
Cliff
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: advice with configuration/scaling a live Pylons app.
On Fri, 2008-05-30 at 11:19 -0700, Shannon -jj Behrens wrote: * There were a couple good points made above about whether to run one or multiple copies of Paster. It's true that this is one place where Pylons/Python is very different from Rails/Ruby, as mentioned above. If you're mostly blocking on IO, then multiple copies won't help much since multithreaded programs are fine in Python if they're IO constrained. If you're blocking on CPU, then multiple copies of Paster running are a really good idea, otherwise the GIL will get in the way of your making use of multiple cores. I'm curious about this. While it's true that unbounded threading can solve blocking issues, what about thread pools? If you get a large number of simultaneous requests and exhaust either your Pylons thread pool or your SQLAlchemy connection pool (I've been having the latter happen frequently when spammers and bots hit my blog), you get problems. What's the solution besides: 1) increasing thread/connection pool sizes 2) running multiple instances Both of these can provide some temporary relief, but I have to admit that my rather low-traffic blog running into the SA connection pool limits was rather discouraging. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Cross-Project code sharing...modules/plugins what does Pylons use?
On Sat, 2008-05-24 at 16:21 -0700, Mike Orr wrote: But then that gets into the issue of the site template. If the inner app should be shown within the global header and sidebar, then you'd have to inherit the site template -- which doesn't work well across apps, plus you'd have to know what variables to set for the site template. Or the outer app could have a controller ACTION (not a whole controller) that calls the inner app to get the page content, and then plugs that into its template. The action could emulate a WSGI server, possibly using WebOb's application-wrapper for convenience. Long ago the topic of portlet-style sites came up on this list and Ian suggested using a subrequest and paste.recursive. Wouldn't a web helper that could do a subrequest be a possible solution? Rather than the plugin inheriting the site template, the site template would perform a subrequest to retrieve the plugin's html. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Cross-Project code sharing...modules/plugins what does Pylons use?
On Sun, 2008-05-25 at 15:27 -0700, Mike Orr wrote: On Sun, May 25, 2008 at 11:49 AM, Cliff Wells [EMAIL PROTECTED] wrote: On Sat, 2008-05-24 at 16:21 -0700, Mike Orr wrote: But then that gets into the issue of the site template. If the inner app should be shown within the global header and sidebar, then you'd have to inherit the site template -- which doesn't work well across apps, plus you'd have to know what variables to set for the site template. Or the outer app could have a controller ACTION (not a whole controller) that calls the inner app to get the page content, and then plugs that into its template. The action could emulate a WSGI server, possibly using WebOb's application-wrapper for convenience. Long ago the topic of portlet-style sites came up on this list and Ian suggested using a subrequest and paste.recursive. Wouldn't a web helper that could do a subrequest be a possible solution? Rather than the plugin inheriting the site template, the site template would perform a subrequest to retrieve the plugin's html. It could. I'm not really a fan of subrequests, seems like a lot of overhead. But in some cases it may be the simplest solution. As I understand it, paste.recursive turns local subrequests into a function call(s) rather than actually making another HTTP request. So there will undoubtedly be a small amount of additional overhead, but not as much as a full subrequest would normally incur. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Getting rid of virtualenv
I know this is OT, but there's plenty of people in the know here, so maybe I can get some help. I decide to give virtualenv a spin on my laptop yesterday to test out some Python package. It didn't work out so I deleted the virtualenv directory I'd created for it, thinking it was an isolated environment. Unfortunately, today I decided to do some work on Breve only to discover that something isn't quite right. Any time I try to run python setup.py install from my Breve source dir, setuptools tries to install python-openid (a requirement of the package I was testing). Clearly some Python system file has been altered. How do I undo this? Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Getting rid of virtualenv
Nevermind. In the tradition of figuring it out 2 minutes after posting a question I've resolved it. And in the interest of fairness, I don't think it was virtualenv's fault. Regards, Cliff On Sat, 2008-05-24 at 14:01 -0700, Cliff Wells wrote: I know this is OT, but there's plenty of people in the know here, so maybe I can get some help. I decide to give virtualenv a spin on my laptop yesterday to test out some Python package. It didn't work out so I deleted the virtualenv directory I'd created for it, thinking it was an isolated environment. Unfortunately, today I decided to do some work on Breve only to discover that something isn't quite right. Any time I try to run python setup.py install from my Breve source dir, setuptools tries to install python-openid (a requirement of the package I was testing). Clearly some Python system file has been altered. How do I undo this? Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deployment Question
On Fri, 2008-05-23 at 10:05 -0400, Ross Vandegrift wrote: I don't think that's such a ridiciulous claim! Consider the application server that hosts the apps that I write for my company's internal use. It hosts four or six Pylons applications and one Rails app. One of these apps handles around 1000 uses a day, one around 100, one around 10. The Rails app is an AJAX form that just pushes collected data to the browser, so is usually busy despite only having an average of 1 user a day. The server these apps are housed on is gratuitously overpowered. Apache's flexability makes this use-case trivial. Maybe this deployment pattern is uncommon? No, I think it's quite common, however I'm one of those obstinate types who refuses to equate popularity with correctness =) I'm more or less done - I think you've convinced me that Nginx is probably worth another look at some point. After all, there's nothing wrong with having another tool around to solve some problem, even if Apache is where I'd go first. Well, I don't want to discount the value of experience. If you know Apache well then that can be a perfectly valid reason to stick with it, especially if you aren't hitting any limitations with it. My main concern in this thread has been to dispell the idea that Nginx is only appropriate in specialized deployments or the inverse that Apache is the best general-purpose webserver. I believe neither to be true, but that doesn't mean that I believe Apache is a *bad* choice, only that unless you are already heavily invested in Apache (existing deployments, trained staff, etc) then perhaps you should consider alternatives. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: How did you begin your fun with Pylons?
On Fri, 2008-05-23 at 11:06 +0200, Raoul Snyman wrote: But this is the exact response I was talking about. Instead of being gracious about something, some developers become defensive and then attack back. And Mike, this is not a personal attack on you, this is a trend I have seen in a number of projects. CakePHP (since I've mentioned them before) do the same thing. When someone is critical about their documentation, they also do the defend and attack response (I've probably done the same with my projects as well). I'm asking this questions because of the low number of tutorials, sh*tty tutorials on Pylons site maybe there's a big boom about 0.9.7? Honestly - I don't think so... If I remember good - it should be on more than a month ago. This seemed more like be attacked and defend by counterattack than defend and attack. The OP is clearly a troll. I suggest we let it go. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deployment Question
On Wed, 2008-05-21 at 17:53 -0700, Graham Dumpleton wrote: On May 22, 5:20 am, Cliff Wells [EMAIL PROTECTED] wrote: I think this is true for all of us. The difference is that the world has changed in the last couple of years and now there's more options to choose from. And by options I don't mean a smaller, less capable Apache clone, I mean a paradigm shift in how to handle high loads. It's well known that threaded/process based servers cannot scale beyond a reasonable point. Nginx and Lighttpd are async and are specifically written to address the C10K problem. There are two approaches one can use for addressing scalability, they are vertical scaling and horizontal scaling. In vertical scaling one just upgrades your existing single machine with a bigger more capable machine. For this path then yes, nginx and lighttpd may give your more head room than Apache. The problem with vertical scaling is cost, plus that you will hit the limit of what the hardware can achieve much sooner than with horizontal scaling. Except that vertical scaling doesn't preclude horizontal scaling, it merely postpones the necessity for implementing it (if not the planning) and helps limit the scope of it. If Nginx provides superior vertical scaling, then it will also provide superior horizontal scaling since vertically scaled systems are the building blocks of a horizontally scaled system. With horizontal scaling you keep your existing machine and just add more machines. For horizontal scaling, the limit is going to be how easy it is to accommodate your application across a growing number of machines. The scalability of Apache here isn't generally going to be an issue as you would have sufficient machines to spread the load so as to not unduly overload a single machine. Although one is buying more hardware with horizontal scaling, the cost/ performance curve would generally increases at a lessor rate than with vertical scaling. Again, I think this contrast is artificial. You are setting up vertical scaling and horizontal scaling as mutually exclusive when they are anything but, and unless you have endlessly deep pockets, you should prefer to control the growth of your horizontal scaling. Of course, there is still a whole lot more to it than that as you need to consider power costs, networking costs for hardware/software load balancing, failover and possible need for multiple data centres distributed over different geographic locations. Absolutely. And while hardware costs are dropping, hosting and power costs are going up. My colocation fees have increased an average of 10% per year, and power fees have quadrupled since I started. I don't expect this trend to change any time soon. One thing that keeps troubling me about some of the discussions here as to what solution may be better than another is that it appear to focus on what solution may be best for static file sharing or proxying etc. One has to keep in mind that Python web applications have different requirements than these use cases. Python web applications also have different needs to PHP applications. Given that an average web page is probably 70% or more static or cached content, I think this is a critical aspect. As I originally pointed out, for Python web applications, in general any solution will do as it isn't the network or the web server arrangement that will be the bottleneck. What does it matter if one solution is twice as fast than another for a simple hello world program, when the actual request time saved by that solution when applied to a real world application is far less than 1% of overall request time. If you try to scale a dynamic application and are going to pass part of the request off to Python on every request you are going to either fail spectacularly or spend an awful lot of money scaling horizontally. There's a reason people have successfully deployed huge Rails apps and it's not often by having 300 servers. They manage it by making sure that Rails is only called when absolutely necessary and letting a fast webserver handle most of the load. In any case, the same techniques are going to be applied regardless of which web server you choose. The question is more how much of my limited and expensive resources is this single part of my stack going to consume and what benefit will I be getting for it? Unless you require a specific module, Nginx and Apache are more-or-less functionally equivalent, except that one uses a fraction of the resources of the other. For non database Python web applications issues such as the GIL, and how multithreading and/or multiple processes are used is going to be a bigger concern and have more impact on performance. This is in as much as running a single multithreaded process isn't going to cut it when scaling. Thus ease of configuring use of multiple processes is more important as is the ability to recycle processes to avoid issues
Re: Deployment Question
On Thu, 2008-05-22 at 00:43 -0700, Cliff Wells wrote: If you try to scale a dynamic application and are going to pass part of the request off to Python on every request you are going to either fail spectacularly or spend an awful lot of money scaling horizontally. There's a reason people have successfully deployed huge Rails apps and it's not often by having 300 servers. They manage it by making sure that Rails is only called when absolutely necessary and letting a fast webserver handle most of the load. Since I think it's of specific interest, here's an interesting approach that could probably be made to work with Apache as well: http://blog.kovyrin.net/2007/08/05/using-nginx-ssi-and-memcache-to-make-your-web-applications-faster/ Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deployment Question
One more option I've not seen mentioned is Cherokee: http://www.cherokee-project.com/ I've never used it in production (last time I experimented with it was a couple years ago and it wasn't mature enough), but it's reported to be quite fast, even edging out Nginx in several benchmarks. http://www.alobbs.com/news/104 It also has native SCGI support and a management interface written in Python. The documentation isn't what it could be, but I expect the admin interface helps out quite a bit on that count. Regards, Cliff On Fri, 2008-05-16 at 13:38 -0700, Jonathan Vanasco wrote: I'm a little unclear on the better ways to deploy a Pylons app. My production servers run nginx -- is it better to use some fastcgi support (if so, how?) or just do a paster serve and proxy to that port? I've read a handful of ways on how-to-deploy apps, and all seem different. I've yet to see a comparison or this is THE way to do it document. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deployment Question
On Tue, 2008-05-20 at 18:13 -0700, Graham Dumpleton wrote: If one really has to use a software proxy, then also perhaps look at dedicated solutions like Pound. It may be the case that nginx serves okay as a proxy, but it isn't purpose built for that and so solutions like Pound may provide a more flexible solution which is easier to configure and manage when load balancing across many machines. I often agree with you in general (despite disagreeing on particular details wink). However you really ought to quit making unfounded generalizations about Nginx. It is, in fact, purpose-built to be a proxy. It's also far better than Pound (which I also used before switching to Nginx) as a proxy. It's true it doesn't (currently) have very sophisticated load-balancing (round-robin only, unless you use a 3rd party module), but it's almost stupidly simple to configure and easily outperforms Pound, especially under load. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deployment Question
On Wed, 2008-05-21 at 01:13 -0700, Graham Dumpleton wrote: On May 21, 5:25 pm, Cliff Wells [EMAIL PROTECTED] wrote: I would say however that mod_proxy module in Apache is also purpose built for proxying, that doesn't mean it is a good idea to use it. The advantage Nginx brings over even purpose-built proxies is its async model. Pound is quite capable and easy to use but has limited scalability due to being threaded. Nginx can handle many thousand requests per second while using only a few megabytes of RAM and a relatively small amount of CPU. What I was trying to say was that where there are solutions whose only purpose is to do something, also look at them as well as those which may do it as one function of many. This is because the solutions which try to do just the one job do often come with a better feature set for that one task, that depending on what you are doing may make more sense. Yes it may mean a drop in performance for some aspects of the problem being solved, but this may be made up in other ways through the other features it provides. Again, in general I'd agree (and I really used to like Pound a lot), but in this case, unless you need sophisticated load-balancing algorithms, it's hard to beat Nginx. Sorry, I am generalising again of course, but when you really don't know the exact details of what a person is wanting to setup and why, it is hard to do anything else. :-) Just because we don't necessarily know exactly what we're arguing about doesn't mean we have to stop ;-) Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deployment Question
On Wed, 2008-05-21 at 11:55 -0400, Ross Vandegrift wrote: On Tue, May 20, 2008 at 02:01:26PM -0700, Cliff Wells wrote: According to Netcraft, Nginx is now deployed in front of over 1 million domains. Not nearly as much as Apache, but clearly not all of those are highly isolated environments. In fact, many sites with heavy traffic are moving to Nginx due to it's vastly superior scalability. Some notables that use Nginx: wordpress.com youtube.com hulu.com rambler.ru torrentreactor.net kongregate.com Where did you get your research from? (Actually, don't answer that, I can guess). Sites that are amongst the largest on the internet fall into a corner case in my mind. As Mike pointed out, sites have an unrealistic expectation of traffic. I've been involved in the average cases. As have I. But I'm going to disassemble this argument below. My claims come from years in the service provider industry, watching various deployments. I've been an Apache fan for a long time, and have seen and deployed hundreds of servers, serving thousands of sites on Apache. I think this is true for all of us. The difference is that the world has changed in the last couple of years and now there's more options to choose from. And by options I don't mean a smaller, less capable Apache clone, I mean a paradigm shift in how to handle high loads. It's well known that threaded/process based servers cannot scale beyond a reasonable point. Nginx and Lighttpd are async and are specifically written to address the C10K problem. As you point out, not all sites need this sort of scalability (certainly none that I've written or hosted), however there's a fallout benefit to this work: these servers can scale specifically because they don't use threads which means they also use *considerably* less memory and also tend to use much less CPU. I challenge you to name any system that won't benefit from reduced RAM and CPU utilization. To give you a concrete example: last week a colleague of mine converted a server running Apache and mod_php to Nginx and FastCGI. Prior to the conversion the server was using almost 1.2GB of RAM. After the conversion he was using 200MB. Is it probable that Apache was misconfigured? Hard to know unless you have spent years tuning Apache, but I'll concede it's possible. Is Nginx misconfigured? Well, frankly it doesn't seem to matter ;-) None are youtube.com - and I agree that this is an important point. Comparing my Apache deployments with deployments of other servers, year after year, Apache won hands down: 1) Users of other HTTP servers are always fiddling with them, restarting after crashes. This may be due to misuse, non-optimal config - I'm not sure. But I've never had stability issues like this with Apache. I had many issues with Lighttpd, but I've had none with Nginx. I'd also have to question your use of always in the above sentence. I strongly suspect aren't speaking from experience here, rather just hearsay. 2) Apache is well-understood by many more folks. There's an army of support reps downstairs that are compentent, if not experts, at maintaining and troubleshooting it. The other servers come across as mysteries (despite often being highly trivial), and end up escalated instead of fixed. And it's poorly understood by just as many, if not more. I first switched from Apache not due to scalability concerns (like you, I've not encountered them), but because I find Apache's configuration to be overwhelming and convoluted. When I first started using Nginx, all the documentation was in Russian and yet I managed to convert an entire shared hosting box from a mix of Apache, Pound, and Lighttpd to Nginx in two days by simply reading the examples. I'd challenge any newcomer to Apache to do the same. The fact that you need an army of support reps isn't really advancing your argument ;-) 3) Documentation for Apache is through, searchable, and understandable. It's full of examples, is available for multiple versions of httpd. I have seen the Apache documentation turn motivated people from competent levels to expert just by googling for it. I'm not saying that other servers don't have decent docs - but Apache's are amongst the best docs for any software I have ever read, and I have seen them function in production for years. I'd never argue it doesn't. In fact, Apache's documentation is clearly far more extensive than Nginx's. I'd expect no less after being the workhorse of LAMP for the last decade. I'll happily admit (well, not too happily) that Apache's documentation is far better than Nginx's. Unfortunately superior documentation doesn't make for superior software. Documentation is fixable, but Apache's process model isn't. I'd qualify this paragraph as some of Apache's strengths are, rather than a blanket it's better. For some people, in some settings, it is better. For others it isn't
Re: Deployment Question
On Tue, 2008-05-20 at 13:49 -0400, Ross Vandegrift wrote: On Mon, May 19, 2008 at 09:10:27PM -0700, Jonathan Vanasco wrote: so is Apache considered to be a good thing (through mod_wsgi , mod_python , or other ?) i've been doing mod_perl dev for years, and have had some experience with mod_python -- generally speaking, my experience is that if you can avoid apache you're better off. i guess that's what is throwing me off. i equate apache with isn't there a better way now? I don't mean to come off as sounding curt, but I've often heard that from people who haven't really maintained the alternatives. Or that have an application that gets deployed in a highly isolated environment, where interoperability means nothing. Funny, over the last couple of years, I've deployed Nginx in front of nearly a hundred websites, ranging from Pylons and TurboGears to PHP and Wordpress down to simple static HTML. According to Netcraft, Nginx is now deployed in front of over 1 million domains. Not nearly as much as Apache, but clearly not all of those are highly isolated environments. In fact, many sites with heavy traffic are moving to Nginx due to it's vastly superior scalability. Some notables that use Nginx: wordpress.com youtube.com hulu.com rambler.ru torrentreactor.net kongregate.com Where did you get your research from? (Actually, don't answer that, I can guess). Frankly, the flexability of Apache is what makes it so much better than the alternatives. It has solid support for just about anything related to the web. It has excellent, complete documentation surrounded by a large, knowledgeable user community. I'd qualify this paragraph as some of Apache's strengths are, rather than a blanket it's better. For some people, in some settings, it is better. For others it isn't. If you need high scalability, it isn't the best. If you need a small memory footprint it's not the best. If you prefer a sane configuration syntax it isn't the best. If you need all three then it's arguably amongst the worst. I equate Apache with There is no better general solution, even though various half-assed alternatives have been cooked up. I certainly intend to sound curt: There are places where Apache is the only possible solution. Personally I've found that to be the minority of deployments where you need specialized modules that are only available on Apache. When you choose Apache you gain a wide array of modules and add-ons that might neatly solve a particular problem, but you sacrifice efficiency, scalability, and simplicity of configuration. Choosing a web server, like any other software selection, is a matter of weighing pros and cons and selecting the one that fits your needs the best. We all have strong opinions about software, but try to stick to reasoned arguments and leave the insults at home, especially when it's abundantly clear you've never even tried (or perhaps even read about) the alternatives. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Upgraded to python 2.5 on centos but cannot get pylons
On Tue, 2008-05-20 at 16:24 -0700, lilinspace wrote: II had pylons working with python 2.4 but now I have upgraded to python 2.5. I tried running easy_install Pylons==0.9.6.1 easy_install hardcodes the path in the shebang line. If 2.5 is installed as /usr/bin/python2.5, try running /usr/bin/python2.5 easy_install Pylons which will cause the shebang line to be ignored. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deployment Question
On Fri, 2008-05-16 at 13:38 -0700, Jonathan Vanasco wrote: I'm a little unclear on the better ways to deploy a Pylons app. My production servers run nginx -- is it better to use some fastcgi support (if so, how?) or just do a paster serve and proxy to that port? I've read a handful of ways on how-to-deploy apps, and all seem different. I've yet to see a comparison or this is THE way to do it document. Probably because THE way can never satisfy everyone =) Personally I proxy Nginx to paster or CP's wsgiserver. I find it a bit easier to debug than FastCGI. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Newbie question - using cgi to serve my app
On Fri, 2008-05-02 at 10:55 -0700, Rudy wrote: Thanks for the reply. The only trouble with redirecting to the paster server is that I don't know if I can leave the paster running after I log out. Right now, I have to log in and start the paster server, then start another login window and run lynx to test the server. When I log out the process gets killed. I can start it as a backround task, but I think it will still be killed when I log out. There's several utilities for managing this (screen, dtach, etc), but the good old-fashioned way is nohup: $ nohup paster serve myapp.cfg Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: notmm-0.2.10p8 released
On Fri, 2008-05-02 at 11:58 -0700, Etienne Robillard wrote: Hi, notmm-0.2.10p8 has just been released yesterday. It sports numerous bug fixes and also have several new features, examples and improved documentation. What is it? There's not much of a description on pypi and the home page is blank. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Multiple Pylons instances, processor affinity, and threads
On Wed, 2008-04-23 at 21:04 -0400, Christopher Weimann wrote: I suppose another option is using a Paste#http instance for each processor and nginx as a reverse proxy spreading the load over them. That's what I do. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Intermittent error on Pylons apps
Actually, the a different traceback that was emailed to me suggests the error might be in docutils, not Pylons. I'll investigate this before bugging the list more. Regards, Cliff On Sun, 2008-04-13 at 22:16 -0700, Cliff Wells wrote: I have intermittent errors on a couple Pylons sites when performing POST operations: Traceback (most recent call last): File /var/www/virtual/twisty-industries.com/lib/python2.5/PasteScript-1.3.6-py2.5.egg/paste/script/wsgiserver/__init__.py, line 624, in communicate req.respond() File /var/www/virtual/twisty-industries.com/lib/python2.5/PasteScript-1.3.6-py2.5.egg/paste/script/wsgiserver/__init__.py, line 357, in respond response = self.wsgi_app(self.environ, self.start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/PasteDeploy-1.3.1-py2.5.egg/paste/deploy/config.py, line 276, in __call__ return self.app(environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/cascade.py, line 92, in __call__ return self.apps[-1](environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/registry.py, line 340, in __call__ app_iter = self.application(environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/recursive.py, line 80, in __call__ return self.application(environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/errordocument.py, line 185, in __call__ app_iter = self.application(environ, change_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/exceptions/errormiddleware.py, line 149, in __call__ response = self.exception_handler(exc_info, environ) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/exceptions/errormiddleware.py, line 178, in exception_handler simple_html_error=simple_html_error) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/exceptions/errormiddleware.py, line 353, in handle_exception exc_data.exception_type, exc_data.exception_value)) IOError: [Errno 5] Input/output error Restarting the application solves the issue for a time, but it inevitably happens again. It doesn't appear to be a hardware or resource issue as it only happens with Pylons apps. The apps affected appear to be limited to ones that have been upgraded from earlier versions of Pylons, but I haven't been able to locate any omissions in my upgrade (and they work for days or weeks without issue). I'll provide source if someone has a suggestion as to which source I should provide =) Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Intermittent error on Pylons apps
I have intermittent errors on a couple Pylons sites when performing POST operations: Traceback (most recent call last): File /var/www/virtual/twisty-industries.com/lib/python2.5/PasteScript-1.3.6-py2.5.egg/paste/script/wsgiserver/__init__.py, line 624, in communicate req.respond() File /var/www/virtual/twisty-industries.com/lib/python2.5/PasteScript-1.3.6-py2.5.egg/paste/script/wsgiserver/__init__.py, line 357, in respond response = self.wsgi_app(self.environ, self.start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/PasteDeploy-1.3.1-py2.5.egg/paste/deploy/config.py, line 276, in __call__ return self.app(environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/cascade.py, line 92, in __call__ return self.apps[-1](environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/registry.py, line 340, in __call__ app_iter = self.application(environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/recursive.py, line 80, in __call__ return self.application(environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/errordocument.py, line 185, in __call__ app_iter = self.application(environ, change_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/exceptions/errormiddleware.py, line 149, in __call__ response = self.exception_handler(exc_info, environ) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/exceptions/errormiddleware.py, line 178, in exception_handler simple_html_error=simple_html_error) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/exceptions/errormiddleware.py, line 353, in handle_exception exc_data.exception_type, exc_data.exception_value)) IOError: [Errno 5] Input/output error Restarting the application solves the issue for a time, but it inevitably happens again. It doesn't appear to be a hardware or resource issue as it only happens with Pylons apps. The apps affected appear to be limited to ones that have been upgraded from earlier versions of Pylons, but I haven't been able to locate any omissions in my upgrade (and they work for days or weeks without issue). I'll provide source if someone has a suggestion as to which source I should provide =) Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: paster shebang line
On Fri, 2008-04-11 at 22:00 -0700, Mike Orr wrote: On Fri, Apr 11, 2008 at 8:55 PM, Cliff Wells [EMAIL PROTECTED] wrote: The method I've been using is documented here: http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation I'd like to add, that except for this one problem I've encountered, it's worked quite well for a few years now. I see virtualenv as solving a problem that was already solved by setuptools itself quite some time ago. This is going to be another of those dumb users issues we clashed about before. Not especially. I'm going to dodge it since it's clear you care about it far more than I do =) Virtualenv, although it's not part of the stdlib, is straightforward and self-contained. You don't have to modify the system Python library to use it, so I don't see why you consider it incompatible with your old environment. It is incompatible for one simple reason: these are existing applications. It's simply not feasible to reinstall a customer's application with no tangible benefit to them. Most of them don't care it's written in Python, let alone that it's not using virtualenv. They won't appreciate the upgrade and they certainly won't pay for it. So more or less, it's an exercise in busy work. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: paster shebang line
On Fri, 2008-04-11 at 22:00 -0700, Mike Orr wrote: On Fri, Apr 11, 2008 at 8:55 PM, Cliff Wells [EMAIL PROTECTED] wrote: The method I've been using is documented here: http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation I'd like to add, that except for this one problem I've encountered, it's worked quite well for a few years now. I see virtualenv as solving a problem that was already solved by setuptools itself quite some time ago. This is going to be another of those dumb users issues we clashed about before. Users are put off by having to read some large and semi-obscure manual that isn't even part of the official Python documentation in order to install packages. What other programming language does this? To top it off, they have to choose from three configuration methods, and some of them involve root changes in the Python distribution. And we have to put that at the *beginning* of the Pylons documentation, before they've even installed Pylons! That really makes Python look like a half-baked programming language. I didn't find this to be particularly convincing, but I will give you some ammunition for if/when this comes up again ;-) I was looking over the virtualenv features and it does in fact, have at least one significant technical advantage over the setuptools way: you can have multiple virtualenvs per user. This is something you wouldn't achieve without some ugly hackery using plain setuptools and actually seems pretty useful in general. With setuptools it's one virtual environment per user, but no more. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: paster shebang line
On Sat, 2008-04-12 at 18:08 -0700, Mike Orr wrote: On Sat, Apr 12, 2008 at 10:12 AM, Cliff Wells [EMAIL PROTECTED] wrote: Virtualenv, although it's not part of the stdlib, is straightforward and self-contained. You don't have to modify the system Python library to use it, so I don't see why you consider it incompatible with your old environment. It is incompatible for one simple reason: these are existing applications. It's simply not feasible to reinstall a customer's application with no tangible benefit to them. Most of them don't care it's written in Python, let alone that it's not using virtualenv. They won't appreciate the upgrade and they certainly won't pay for it. So more or less, it's an exercise in busy work. Who said anything about reinstalling customer applications? I did. In the post that started this thread. If they're working, they're working. They were working until I upgraded the system Python from 2.4 to 2.5. I have both versions installed but /usr/bin/python is no longer 2.4. Hence my original complaint about distutils putting /usr/bin/python as the shebang line. The original issue has gotten conflated with our wandering argument, but I was addressing your specific statement as to why virtualenv wasn't compatible with my setup, rather than the argument as a whole. Probably I should mention that this system is Gentoo, which means that upgrading the system Python is an expected thing to do on occassion. If you've got a global install of Setuptools, it's fine.. at least until you have to install an app that needs a different version of a package than another app on the system needs. pkg_resources.require() would be great except that many apps including Paster have no place to specify the versions before the modules are imported. You could hack it into the stub executable, but then there's one more problem with installing Pylons apps via setup.py -- it overwrites the stub script. This is going to be another of those dumb users issues we clashed about before. Not especially. I'm going to dodge it since it's clear you care about it far more than I do =) I feel strongly about it because I've written several HOWTOs that needed this as a preamble, and I always feel apologetic about it. Well, I still feel pretty firmly that what we've discussed is well within the abilities of even an average Python programmer to handle. I certainly appreciate any efforts to simplify development tasks, but I also have a bit of disdain for the dumbing down mentality that seems to be pervading software in recent times. If it was hard to write, it should be hard to use wink. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: paster shebang line
On Sat, 2008-04-12 at 16:51 -0500, Ian Bicking wrote: In a virtualenv context you wouldn't have had any problem. So... I can only say that future people will not have this problem, but there's nothing that can be done about your problem. Except for you to update the #! lines, which clearly you'll have to do anyway. I was pointed to the correct way to do this, which is to simply run easy_install again which will update the shebang lines for you. virtualenv is very much meant to keep working code working, and I think it does that. So there is a current answer to that problem. Yes, I'm turning around on virtualenv. Unfortunately there's not a lot to be done for legacy installs but it will certainly be a consideration for new installs. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: paster shebang line
On Fri, 2008-04-11 at 19:06 -0500, Ian Bicking wrote: Cliff Wells wrote: Is there a particular reason paster uses #!/usr/bin/python rather than #!/usr/bin/env python Having an absolute path to a system directory prevents symlinking a different version of python in a user directory, ignores PATH, etc. In short, it seems the wrong thing to do on Unix. It does what Setuptools does -- Paste itself doesn't create that shebang line. This is actually quite important for virtualenv scripts, as it's what selects the environment that you are running in. This bit me because I upgraded a hosting box to Python 2.5 but not all the applications were ready for this. Each site has ~/bin as the first item in PATH, so it was pretty trivial to simply add a symlink to /usr/bin/python2.4 to this directory and have most applications pick it right up and continue working. Unfortunately I had to patch paster for all of the sites using Pylons since they were hard-coded to /usr/bin/python (which was now python2.5). I'm not quite convinced that this is the absolute right way to do it. Virtualenv could just as easily rely on PATH like every other Unix application (and this gives the sys admin much better control, especially in case of an upgrade). Regardless, if this is a setuptools issue, I'll take my complaint there =) Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons + Google App Engine
On Wed, 2008-04-09 at 08:50 -0700, Mike Orr wrote: The problem with C libraries is a lot bigger than just Google. It frustrates users on Windows and Macintosh to no end, and many of them give up trying to install Pylons/lxml/ToscaWidgets/wxPython and go on to something else. Precompiled binaries don't always exist, are too old, hard to find, or built with the wrong C compiler or Unicode width. I think this is less true that it used to be. Microsoft now makes a free version of Visual Studio available which is sufficient to compile Python extensions on Windows: http://www.microsoft.com/express/download/ I've only used it once, several months ago, but it seemed to work fine. I think issues people might have with this will be documentation issues. As far as Mac, I don't think C extensions are much of an issue (unless you include OS9). Obviously C extensions that aren't written in a portable way are going to be a problem, but that's *their* problem. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Hint: In case you are looking for button_to_remote
On Sun, 2008-02-17 at 13:06 -0800, Eric Ongerth wrote: So, you're thinking, OK, we have link_to_remote, which is what I've already used successfully to get one of my controllers to send back some text into my div, AJAX-style. Therefore why no button_to_remote? Why can I only do this with a plain text link and not with a stylish button? Or just use CSS to style the link to look like a button? Lots of people do this anyway since styling buttons isn't well supported across browsers. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Having some trouble getting started with Pylons
On Mon, 2008-01-28 at 06:38 -0800, walterbyrd wrote:
Now I'm having new troubles. I keep getting this error:
ValueError: bad marshal data
I have no idea what this means.
It means you have corrupt .pyc files. If you're on *nix you can just
execute:
find myPylonsApp -name *.pyc -exec rm {} \;
If that doesn't fix it, you might need to do the same thing in your
site-packages directory, but that's less likely.
Regards,
Cliff
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Publishing application with avahi
On Mon, 2008-01-28 at 16:23 -0500, Chris AtLee wrote: Hello Pyloneers, For one of the applications I'm writing, it would be really handy to have the app advertise itself with avahi so that clients on the network could automatically find it. What I've got so far is the following, which has been added to Globals.__init__: publishInfo = config.get(publish_url) # e.g. http://hostname.mydomain.com:5002 if publishInfo: appname = config.get(package) s = urlparse.urlparse(publishInfo) hostname = s.hostname port = str(s.port) url = s.path args = [avahi-publish-service, appname, _%s._tcp % appname, port] if url: args.append(url) try: self.avahiRegistration = subprocess.Popen(args, close_fds=True) except OSError: log.warning(Couldn't start avahi-publish-service) This kind of works...The problem so far is that when the application is run under paste with the --reload option, the child avahi-publish-service processes don't get killed off when the application is shutdown. When paster restarts the application, the old avahi process is re-parented to the init process. The same problem occurs when running with --daemon. Have you tried using the Avahi Python bindings? I'd expect that to work far better than opening a subprocess. Regards, Cliff Is there a way to get notified when your application is about to be shut down? Paste looks like it just sends SIGTERM to the process when it detects a modified file, but maybe I'm missing something. Maybe there's a better approach I could be taking? Thanks! Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Having some trouble getting started with Pylons
On Sun, 2008-01-27 at 09:04 -0800, walterbyrd wrote: Here is what I have: /var/www/helloworld# ls *.ini development.ini test.ini /var/www/helloworld# wget http://127.0.0.1:8080 --09:54:01-- http://127.0.0.1:8080/ = `index.html.3' Connecting to 127.0.0.1:8080... failed: Connection refused. Is that okay? I'm going to be frank: you aren't giving anywhere near enough information for anyone to help you. Did you actually start pylons with paster serve development.ini? Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Having some trouble getting started with Pylons
On Sat, 2008-01-26 at 05:16 -0800, walterbyrd wrote: On Jan 26, 12:03 am, Cliff Wells [EMAIL PROTECTED] wrote: 3) run links (in the VPS) and try to connect to 127.0.0.1:5000 I edited development.ini, and set the host back to it's default of 0.0.0.0. I tried connecting with 127.0.0.1:5000, but I got the same connection refused error. If I run links, and connect to 127.0.0.1 with no port specified, it works just like connecting to the site from outside with real_ip. If it connects with no port specified, then it is connecting to port 80. It's certainly not connecting directly to Pylons. I am using lighttpd as my primary web server. I am not using a proxy, I don't have any traffic yet. If you are already running Lighty, why not just have it proxy to the Pylons app? Avoiding this is just making your life more difficult. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Having some trouble getting started with Pylons
On Sat, 2008-01-26 at 05:16 -0800, walterbyrd wrote: On Jan 26, 12:03 am, Cliff Wells [EMAIL PROTECTED] wrote: 3) run links (in the VPS) and try to connect to 127.0.0.1:5000 I edited development.ini, and set the host back to it's default of 0.0.0.0. I tried connecting with 127.0.0.1:5000, but I got the same connection refused error. Sorry, I think I misread this in my previous reply. By I tried connecting with 127.0.0.1:5000 you mean you tried to use links to connect to that port/address? If you can't connect over localhost, then you've got a misconfiguration in your firewall or somehow you aren't doing what you think you're doing with Pylons. Does your Pylons config reference another .ini file? Maybe the port is getting overridden there. And I don't want to sound condescending, but are you sure you're using the .ini file that you've been editing? The problem you are having seems so unlikely that I think you need to recheck your assumptions at every step. Also, you should check your system logs. If it's a system misconfiguration issue (i.e. firewall) you should see something show up there when you try to connect. If I run links, and connect to 127.0.0.1 with no port specified, it works just like connecting to the site from outside with real_ip. That's expected. I am using lighttpd as my primary web server. I am not using a proxy, I don't have any traffic yet. I stand by my earlier statement that avoiding using Lighty as a proxy is misguided. It might sound more complex, but in reality it's probably simpler (and more secure) than the options. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Template knowing the path to static files
On Tue, 2008-01-22 at 11:11 -0800, Matt Haggard wrote: I've been developing without the filter option, and now that I have it, my hard-coded image paths no longer work. (e.g. they're looking at http://127.0.0.1:5000/images/something.gif when they should be looking at http://127.0.0.1:5000/myapp/images/something.gif ) Why not just use a webserver (Nginx, Apache, etc) to serve them? Then you simply setup a handler for that location (/images) and your problem goes away.. You get the added benefit of things getting significantly faster. I strongly suspect (although I haven't tested) that using Pylons to serve static files isn't going to deploy well in the real world (unless you are expecting very little traffic). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Having some trouble getting started with Pylons
On Tue, 2008-01-22 at 11:38 -0800, Mike Orr wrote: On Jan 22, 2008 8:53 AM, walterbyrd [EMAIL PROTECTED] wrote: I have been trying to follow the install instructions here. http://wiki.pylonshq.com/display/pylonsdocs/Home Everything was going okay until I tried this: wb:/var/www/helloworld# paster serve --reload development.ini Starting subprocess with file monitor Starting server in PID 3751. 09:45:52,844 INFO [paste.httpserver.ThreadPool] Cannot use kill_thread_limit as ctypes/killthread is not available serving on 0.0.0.0:5000 view at http://127.0.0.1:5000 I am not doing this on my local system. I am using VPS hosting. I think the problem is with the 127.0.0.1 address. But I am not sure how to fix it. The message means your platform doesn't have a certain threading feature, or possibly that a C file was misconfigured at compilation. It looks like he doesn't have ctypes for some reason (probably Python 2.4). As an aside, once you've fixed this you'll start getting a different INFO message on occassion informing you that 0 threads were killed =) Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Template knowing the path to static files
On Tue, 2008-01-22 at 19:37 -0800, Mike Orr wrote:
You'll have to set up a handler for each file/directory in public if you want
to
do this, or put everything in a subdirectory of public which will appear in
the
URL (public/static/images - /static/images). Unless there's a way to make
Apache fall back to the application if a static file doesn't exist.
It's not well documented how to do this. You're not actually setting
up a handler for the static files. You're setting up a handler for
the Pylons app and then disabling it for certain sub-URLs. With
mod_proxy it would be:
DocumentRoot /myapp/myapp/public
ProxyPass/ http://127.0.0.1:8080/
ProxyPass/images !
With mod_scgi you'd do something like:
Location /images
SCGIHandler Off
/Location
Each handler has a different way to disable itself. There may be some
that can't be disabled at all.
I don't use Apache, but here's what I would do in Nginx:
server {
listen 1.2.3.4:80;
server_name www.example.com;
error_page 404 /404; # goes to Pylons app
location / {
proxy_pass http://127.0.0.1:8000$request_uri;
include /etc/nginx/proxy.conf;
}
# static files location
location ~* ^/(static|images|javascript|js|css|flash|media|
downloads)/$ {
root /path/to/public;
}
}
and my directory layout just looks like:
/path/to/public/static
/path/to/public/images
etc.
If you wanted to preserve the requested URI to pass to your controller,
you could use a conditional redirect instead:
server {
listen 1.2.3.4:80;
server_name www.example.com;
location / {
proxy_pass http://127.0.0.1:8000$request_uri;
include /etc/nginx/proxy.conf;
}
# static files location
location ~* ^/(static|images|javascript|js|css|flash|media|downloads)/$ {
root /path/to/public;
if (!-f $request_filename) {
rewrite (.*) /404?page=$request_uri redirect;
}
}
}
Personally, I let Nginx handle 404's for the most part. Bots (most of
them checking for hackable versions of PHP apps it seems) can generate a
ton of 404's.
Hope that helps someone.
Regards,
Cliff
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Where in the reference docs is h.url_for (and other 'globals')?
On Tue, 2008-01-08 at 21:46 -0500, Yannick Gingras wrote: John_Nowlan [EMAIL PROTECTED] writes: Aren't docs supposed to help alleviate the need to go to the source? In `paster shell`, in a template, or in a controller action, you can do: print h.url_for.__module__ So you're agreeing with him? Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Running pylons with nginx + mod_wsgi
On Fri, 2007-11-16 at 23:34 +0200, Mikael Lepistö wrote: Hi! Has anybody actually managed to configure nginx + mod_wsgi to work with pylons? I manage to load static content from public directory, but for some reason I can't get requests to map to controllers and actions. Is there any special tricks needed for development.ini or startup_script.wsgi? Is there a particular reason you're using mod_wsgi (which is still alpha-quality AFAIK) rather than simply using Nginx to proxy to Pylons? There are a couple pretty big downsides to mod_wsgi and not many upsides that I'm aware of. If performance is your concern, you can get a moderate boost by using CherryPy's wsgiserver in place of Paste's http server. You can also use Nginx to proxy to multiple Pylons backends. If you really feel you need to use this module for some reason, I'd suggest talking directly to Manlio Perillo (the developer). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Reducing pylons app memory usage?
On Thu, 2007-10-18 at 12:18 +0200, Marcin Kasperski wrote: I am watching with interest efforts to port WSGI to nginx which show up on some lists. Nevertheless, it seems it will take some time... Actually I believe Manlio's implementation is usable right now for WSGI 2.0, with WSGI 1.0 support slated for the next release. http://hg.mperillo.ath.cx/nginx/mod_wsgi/ Regardless, WSGI support isn't required to run Pylons under Nginx. I personally use plain HTTP proxying and am quite satisfied. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Reducing pylons app memory usage?
On Mon, 2007-10-22 at 23:24 +, Graham Dumpleton wrote: The complexity I am referring to is not in configuring nginx, but that you also have to install and configure some separate supervisor system which starts up and ensures that your backend process is running. I think this argument doesn't really hold. Either you have to install a supervisor process or you don't. If you do have to, then you arguably need to install one for Apache as well, so the complexity is equivalent. If you don't have to (I've had Pylons and TurboGears sites up for months without restarts or supervisors), then once again the complexity is even. You also need to integrate that into the system startup scripts whereas web servers such as Apache on prepackaged Linux distributions generally have that. If by integrate you mean add a line or two to /etc/rc.local (or your distro's equivalent), then I'll agree with you, but simultaneously fail to see your point. This is extra software dependencies and extra work to setup. I'll take this added complexity, subtract the complexity of reducing Apache's memory footprint and still come out with an overall savings in complexity. I'll agree that Apache can be made more efficient (ignoring the threading vs async debate) but doing so is far more complicated and error-prone than installing Nginx and a supervisor. Apache starts out big and must be pruned down, Nginx starts out small and pretty much stays there regardless. Although it may be manageable if you are running a single web application, it becomes a lot more work if you want to run a mix of web applications, or multiple sites, all in distinct processes as you may then need separate supervisor configurations and startup scripts for each. Since the OP mentioned 96MB of RAM, I'll assume he's running single web app. Unless he requires mod_svn or some other esoteric module, there's simply no way Apache can win here. Because Apache when using appropriate modules can itself act as the supervisor for the applications, it all becomes somewhat simpler as the configuration is all in one spot and all the startup scripts become irrelevant as that would already exist for Apache. I know this is difficult for an Apache expert to grok, but configuring Apache is everything except easy to understand. Some of this is due to Apache's rather large feature-set, but some of it is also due to Apache's rather weird and limited configuration syntax. Also, as I keep trying to put out, speed of request handling and proxying is generally not the problem as your bottleneck is more often than not going to be in your Python web application or in the way it interacts with a database. Thus, for most it would be far more important to use a system which has less dependencies on third party packages and is easier to setup. In general I agree, but if Apache is sucking down 1/10th or more of your memory (and with 96MB, that's certainly likely), then it will certainly reduce overall system performance significantly as disk caching will suffer and you'll be forced to swap much sooner. True, the answer may not always be Apache, especially, if forced to use a memory constrained environment more tailored to PHP web application hosting. I generally find Apache preferable to Nginx when one or more of the following conditions is present: 1) Some esoteric feature of Apache is needed. 2) The customer/user is an Apache expert. 3) I don't care about the installation and hope someone else has to maintain it. If Python folks expect to work within the constrained environments offered for PHP web applications, then the large frameworks have to find ways of cutting down on memory use somehow. I'm not sure the blame is being aimed in the right direction here. I don't think PHP is what Pylons is competing with and I have a definite concern that tailoring it to run in a $7/month hosting account would require too deep of cuts. RoR is much more of a direct competitor, and has been noted, Pylons uses a fraction of the RAM RoR does (not to mention CPU). Quite frankly, were I consulting with a customer in the same position as the OP, what I'd be suggesting is they quit trying to run their site in a toy environment. I think a 96MB VPS is fine for testing, but not a realistic deployment environment for much more than a personal blog or photo album. As an aside, my Pylons (paste+cherrypy) app for Breve only uses around 48MB after a couple months of uptime (there are four Pylons backends load balanced by Nginx): hosting ~ # ps -U twisty -o rss,vsz,command RSSVSZ COMMAND 48000 132720 /usr/bin/python /var/www/virtual/twisty-industries.com//bin/paster serve breve1.ini 48312 133264 /usr/bin/python /var/www/virtual/twisty-industries.com//bin/paster serve breve2.ini 46024 130860 /usr/bin/python /var/www/virtual/twisty-industries.com//bin/paster serve breve3.ini 47920 132860 /usr/bin/python
Re: Locking a page?
On Thu, 2007-09-06 at 17:07 -0400, David Turner wrote: Don't do this. There is no way to make 100% certain that you don't end up with stale locks. Sure, you can have an ajaxy thing that pings the server every minute or so to say, I'm still editing this, but then the user goes off to lunch and everyone is stuck until they get home. If you're using JS anyway, I'd use a combination of short-refresh server-side locks (maybe 30s interval, with AJAX polling from the client to keep the lock alive) and a keystroke client-side lock with a longer (30m?) interval. If the user doesn't interact with the form for 30m, consider it unlocked and alert the user. Or a malicious user can lock up all your pages forever. Don't allow malicious users to edit your pages? =) Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp
On Sat, 2007-08-25 at 20:24 +0300, Pekka Jääskeläinen wrote: On 8/25/07, Ben Bangert [EMAIL PROTECTED] wrote: I'd highly suggest memcached rather than database backend. It's easy to setup, and of course, very fast. :) Yes, but as far as I know, memcached objects can be always replaced, that is, you cannot define an object to be persistent, can you? Thus, one also needs to back up the session data to a persistent storage so it does not get replaced when the cache fills up. This is a good point and is reiterated here: http://www.socialtext.net/memcached/index.cgi?sessions Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons datagrid? And when will TG merge?
On Thu, 2007-08-23 at 21:12 -0700, walterbyrd wrote: Does Pylons have a datagrid component? Data laid out in a table, and click the column header to sort by that column. I am looking for something with basic CRUD, and a sort filter. Also something that can handle related data. I'd recommend looking at ExtJS. I'm unaware of any other open source JS library with a more advanced grid. Integration with Pylons is pretty straightforward. I've used it for a few projects now and can't recommend it highly enough. http://extjs.com/deploy/ext/docs/ (See Examples and Demos - Grid in the tree on the left). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons datagrid? And when will TG merge?
On Fri, 2007-08-24 at 06:04 -0700, walterbyrd wrote: On Aug 24, 4:23 am, Cliff Wells [EMAIL PROTECTED] wrote: I'd recommend looking at ExtJS. I'm unaware of any other open source JS But doesn't that only handle the front end stuff? What about the back- end logic? The grid control calls your controller and it returns jsonified rows for the grid to display. It's pretty simple. You don't need support from Pylons to do it and I actually suspect that relying on built-in support might prove limiting. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp
On Fri, 2007-08-24 at 14:41 +0300, Pekka Jääskeläinen wrote: However, we started to think the practical issues with this in Pylons. In principle, making this work reliably means to distribute the session data so all server processes can access each session's data. I'm curious about this too. I've been actually doing it already for some time (albeit not on any heavily loaded sites) using Nginx and a default Pylons setup and quite frankly I've not had any issues despite taking no precautions. My only possible explanation is that either a) Nginx makes some attempt to track sessions itself and always passes the same IP back to the same backend Pylons process or b) Pylons automagically makes it work. Either way I'd like to feel a little more certain about this. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp
On Fri, 2007-08-24 at 15:16 -0700, Cliff Wells wrote: On Fri, 2007-08-24 at 14:41 +0300, Pekka Jääskeläinen wrote: However, we started to think the practical issues with this in Pylons. In principle, making this work reliably means to distribute the session data so all server processes can access each session's data. I'm curious about this too. I've been actually doing it already for some time (albeit not on any heavily loaded sites) using Nginx and a default Pylons setup and quite frankly I've not had any issues despite taking no precautions. My only possible explanation is that either a) Nginx makes some attempt to track sessions itself and always passes the same IP back to the same backend Pylons process or b) Pylons automagically makes it work. Either way I'd like to feel a little more certain about this. Just to clarify: I'm not load balancing across multiple servers, just multiple Pylons backends on the same machine. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp
On Sat, 2007-08-25 at 01:46 +0300, Pekka Jääskeläinen wrote: On 8/25/07, Cliff Wells [EMAIL PROTECTED] wrote: My only possible explanation is that either a) Nginx makes some attempt to track sessions itself and always passes the same IP back to the same backend Pylons process or b) Pylons automagically makes it work. ...or c) you don't use much the session data storage and you've been lucky. I think I'd have had to have been *much* luckier than I can take credit for ;-) On the other hand... if session data is always stored to the disk to the same directory and location and loaded on each request, multiple server processes accessing the same data should actually work quite fine. This seems the likely answer. To scale this to multiple server machines one would need a networked file system mount point in which to store the session data. However, I'd like to avoid using the disk as much as possible. Memcached seems the easiest (and probably best) solution. As Philip mentions, however, it isn't well-documented how to use Beaker with Memcached. If you decide to go this route, maybe update the wiki? Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp
On Sat, 2007-08-25 at 01:42 +0300, Pekka Jääskeläinen wrote: Apache 2.2 has a mod_proxy_balancer. If performance is a concern, you should go with the CherryPy WSGI server. use = egg:PasteScript#cherrypy instead of use egg:Paste#httpserver This didn't work, I changed the line use = egg:Paste#http to use egg:Paste#cherrypy This is wrong AFAIK. I'm using CP's wsgiserver (which is a standalone app and included with Paste, so you don't actually need to install CP3, although you certainly can), and this is my entry: [server:main] # use = egg:Paste#http use = egg:PasteScript#cherrypy Note PasteScript vs Paste. As an aside, my light testing with ab showed CP3's wsgiserver to be considerably faster than Paste's http server, but also seemed to fail under load slightly more often (more failed requests, not crashes). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: [Paste] Can't start pylons app
On Wed, 2007-08-15 at 19:15 +0200, Neil Blakey-Milner wrote: Or, even better, use virtual-python or workingenv, and never install moving targets into your core Python library location. Out of curiosity, what does workingenv offer over the standard setuptools way of doing things? http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons 0.9.6rc2 and AuthKit
Nevermind, I got 0.4 working well enough. On Sat, 2007-08-11 at 19:26 -0700, Cliff Wells wrote: I just started migrating my first Pylons app from 0.9.4 to 0.9.6rc2. Of course I'm running into problems with AuthKit (0.3.0pre5). I could probably hack them out, but I see right away that AuthKit 0.4presomething is kinda available and the docs for it are kinda available... should I upgrade or try to hack it out with my current version (I'm not doing anything special)? I guess the question boils down to: which version will work the best with 0.9.6? Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Are my Python/Pylons concerns justified?
On Sat, 2007-08-11 at 13:51 -0700, walterbyrd wrote: On Aug 9, 4:35 am, Marcin Kasperski [EMAIL PROTECTED] wrote: A lot of answers already, so just two points: a) There are plenty of cheap VPS hosting options (you get I guess it depends on what you call cheap. I can get php5 hosting for $10/year (http://dollar-hosting.net/). And I expect you get what you pay for. To be frank someone who's only willing to pay $10/year for hosting probably isn't too picky and I'd expect this lack of...um... discrimination to extend to the development stack as well (if you pay this little, expect to use PHP). It's a bit like pointing out that you can buy a new Hyundai for $6000 and then complaining *to Dodge* that their V10 Hemi engine doesn't fit in it. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: page caching in mako and pylons
On Sat, 2007-08-11 at 11:19 -0700, Ben Bangert wrote: You bet, you can cache any part of your templates (their fragments), and you can cache function calls as well. This extends not just throughout Mako, but into Pylons as well, where you can register functions in your controllers to be cached, like the example in the docs here: http://wiki.pylonshq.com/display/pylonsdocs/Caching+in+Templates+and +Controllers In the cache object example, an entire function is handed to the caching system, which can handle any object/output that can be pickled. Is there some way to verify that caching is working (aside from turning up database logging that is)? Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: page caching in mako and pylons
On Sat, 2007-08-11 at 16:25 -0700, Cliff Wells wrote: Is there some way to verify that caching is working (aside from turning up database logging that is)? Nevermind. I got it. Also, it would be useful if Memcached support were added as an option. An interesting article here: http://blog.kovyrin.net/2007/08/05/using-nginx-ssi-and-memcache-to-make-your-web-applications-faster/ It talks mostly about RoR, but the concept is generally applicable. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Pylons 0.9.6rc2 and AuthKit
I just started migrating my first Pylons app from 0.9.4 to 0.9.6rc2. Of course I'm running into problems with AuthKit (0.3.0pre5). I could probably hack them out, but I see right away that AuthKit 0.4presomething is kinda available and the docs for it are kinda available... should I upgrade or try to hack it out with my current version (I'm not doing anything special)? I guess the question boils down to: which version will work the best with 0.9.6? Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Comet Style App
On Tue, 2007-07-24 at 22:33 -0700, Jose Galvez wrote: take a look at this thread http://groups.google.com/group/pylons-discuss/tree/browse_frm/thread/a9231b21bbcc88a0/182469d3700eeda1?rnum=1q=Response+and+sending+content+to+the+browser_done=%2Fgroup%2Fpylons-discuss%2Fbrowse_frm%2Fthread%2Fa9231b21bbcc88a0%3Ftvc%3D1%26q%3DResponse%2Band%2Bsending%2Bcontent%2Bto%2Bthe%2Bbrowser%26#doc_182469d3700eeda1 http://groups.google.com/group/pylons-discuss/tree/browse_frm/thread/a9231b21bbcc88a0/182469d3700eeda1?rnum=1q=Response+and+sending+content+to+the+browser_done=%2Fgroup%2Fpylons-discuss%2Fbrowse_frm%2Fthread%2Fa9231b21bbcc88a0%3Ftvc%3D1%26q%3DResponse%2Band%2Bsending%2Bcontent%2Bto%2Bthe%2Bbrowser%26#doc_182469d3700eeda1 Yow! tinyurl anyone? Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Trying to understand about Paste and web-server requirements
On Wed, 2007-07-25 at 12:12 -0700, walterbyrd wrote: On So Pylons requires fastcgi or mod_python, just like django or turbogears. It should also be noted TurboGears doesn't require FastCGI or mod_python either, as CherryPy is both a framework and an HTTP server. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Trying to understand about Paste and web-server requirements
On Wed, 2007-07-25 at 12:12 -0700, walterbyrd wrote: On Jul 25, 6:04 am, Thomas Sidwick [EMAIL PROTECTED] wrote: Paste provides the glue that sticks these components together in a stack and allows them to communicate. Paste also provides a library of ready made middleware that can integrate functionality into your application. So Pylons requires fastcgi or mod_python, just like django or turbogears. It doesn't. Paste provides an HTTP server. You can let it serve directly, or, more likely, put it behind another HTTP server that can proxy (I personally recommend Nginx, but lots of people use Apache/mod_proxy or Lighttpd). The advantage of of proxying is that you can let the proxy server also serve up static content (images, css) and this will be *much* faster than letting Pylons serve it. There's been some discussion on this list whether FastCGI is any faster than proxying but the results appear to be inconclusive. Either way, proxying is typically a bit easier to setup than FastCGI. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons Logo Design
On Fri, 2007-06-01 at 09:57 +0100, James Gardner wrote: Ben and I have started thinking again about what really makes Pylons different from other web frameworks and how we can best highlight those differences in the Pylons marketing to help attract people to the community and see Pylons gain further recognition and adoption. I'd just like to pipe up with my two cents. 1) I like the current logo, especially as it's used in the powered by image. 2) As far as the project name goes, Pylons may not be wonderful, but it's certainly no worse than TurboGears or Ruby on Rails. 3) As far as the URL, pylonshq.org isn't wonderful, but at least it's short, and frankly I doubt it matters. People don't type URLs, they click links. No one cares. I would be tempted to get all of pylonshq.com/org and pylons-hq.com/org just to help people who do typo them in and aren't 100% certain of the spelling. Overall, I think the key thing to remember here is that the target audience is developers and I don't think these are going to be the primary concerns for a developer visiting the site for the first time. Here's a few things I *do* think are important: 1) Overall finish. I know this is part of what this thread is about, but I think focusing too much on the details (logo, URL, etc) and ignoring the larger picture is a mistake. The site needs to look polished and that involves a bigger vision. I'd prioritize it roughly as: organization, color schemes, logo. The biggest problem with the current site revolves around the first two items. Honestly the color scheme isn't bad (mochikit.com uses similar colors to good effect), but it needs better organization to make it appear more friendly to first-time visitors (the three-box navigation mochikit and 1000 other sites present may be a bit overused, but frankly that's because it's so effective). 2) Fast information. RoR (and then TG) showed the power of the screencast. People want a quick overview of how things are done in a framework. Screencasts turned out to be excellent for this purpose. 3) Completeness. Right now there are out-of-date examples, off-site links related to core features, examples that openly question whether they are doing it right, etc. Documentation is important and new visitors are going to at least peruse it to see if it looks adequate to stake their projects on. Even if we can't have complete docs, we need to at least fix what's there. 4) References. Know of a large/cool/hip site that uses Pylons? Get it on the front page. A big concern for developers is whether or not a framework can handle their site without tons of hardware and hair-pulling (although somehow RoR seems to transcend that requirement). Django at least gets 3 and 4 dead on, and this is arguably the root of much of that project's success. RoR gets 1,2 and 4 right (even if 4 is badly misleading). TG gets 1 mostly right, 2 mostly right, fakes 3 and is catching up on 4. Pylons doesn't get any right, but at least fakes 3 almost as good as TG. I'm not complaining about the current state (well, aside from docs), but if there's going to be a big push to address Pylon's marketing, I think these are far more important than a logo. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: 'Pylons - carries the load'
On Tue, 2007-06-05 at 23:01 -0700, Mike Orr wrote: It's interesting that Zope, Twisted, TurboGears, and now Pylons are all splitting up from one big package into several smaller packages that can be used in other frameworks. Zope has spun off ZODB and is in the process of spinning off other components. TG has spun off ToscaWidgets and wants to spin off others. That's a kind of convergence too. It was Ian Bicking who said, it doesn't matter if there are a lot of frameworks as long as they are interoperable. Interoperability is not only Pylons' feature but its vision, so maybe that should be in the brand somewhere. Power adapter? Or a punnish power adopter? Personally I'm fond of Pylons, the juice is loose! but some might not find it funny ;-) Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Using pater with other servers
On Wed, 2007-05-30 at 04:57 -0700, voltron wrote: http://hiawatha.leisink.org/ the fact that Hiawatha's source code is free of security-bugs, makes Hiawatha the most secure webserver available. besides stating the obvious in a rather unbelievable way, this assertion is followed by: Copyright (c) by Hugo Leisink | Powered by Hiawatha v5.8 | Generated in 1180924509.4455 seconds I'm not sure how much faith I'd put in the first assertion in light of the second :P Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Common files for a multi-app
On Fri, 2007-05-18 at 20:22 +, [EMAIL PROTECTED] wrote: I have been working with Pylons and have developed some standalone applications that are part of a larger site. I'm trying to find out what the best way is to reference common css/javascript files across all of the apps. Here is the setup in a nutshell: I think what you'll find is that you don't want to have Pylons serve these files anyway. Simply define a common directory (outside any of the application's directories) and let a real webserver (Nginx, Apache, Lighttpd, etc) serve those files and leave Pylons for serving dynamic content. Hundreds of times faster and your problem becomes moot as a side-effect. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Iteration in Mako templates
On Wed, 2007-05-16 at 14:10 -0400, Michael Bayer wrote: On May 16, 2007, at 12:34 PM, Dan wrote: The choice between CSS 'tables' and HTML 'tables' is purely a matter of opinion. Just to point out a totally different point-of-view, please see: http://www.decloak.com/Dev/CSSTables/CSS_Tables_01.aspx theres an argument to use table tags for sure...but that guy's nuts. Nuts is being kind. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Paster server in production
On Tue, 2007-05-15 at 17:34 +, __wyatt wrote: On May 15, 12:56 am, voltron [EMAIL PROTECTED] wrote: Hi all I have taken the advice from this forum and have installed nginx as a proxy to the paster server. this works well, but I´m really, really worried about using the Paster server in a production site, for example, when testing a Mako template, the server just died. Are there tips out there to ensure stability? Or at least to make sure that all types of errors are handled gracefully? I'm not sure this is a Paster issue. I think any back end server will crash on an unhandled exception. You could wrap all your render_response calls in a try/except (via a custom render_response method, say) and email any unexpected errors to yourself. Or something of that nature... Hm, this is what mine does already (exceptions don't crash Paster, but I do get an email containing the exception). Perhaps this segment from my .ini file does it? [DEFAULT] debug = false email_to = [EMAIL PROTECTED] smtp_server = localhost error_email_from = [EMAIL PROTECTED] I haven't looked at the source, but possibly setting these values enables exception handling in Paster that isn't on by default. Also, since you're using Nginx, I *highly* recommend setting up multiple backends as outlined here: http://blog.twisty-industries.com/users/cliff/load-balancing-for-turbogears-using-nginx These instructions are easily applicable to Pylons/Paste as well as TurboGears. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Serving static content
On Mon, 2007-04-30 at 10:34 -0700, voltron wrote:
Thanks for your answers Cliff. I took a look at Nginx, it looks very
interesting, would you care to post an example of your Nginx config
file?
Here's a pretty basic setup that proxies to a Pylons backend and serves
static content from a particular directory:
# server section from nginx.conf
server {
listen123.123.123.123:80;
server_name www.example.com example.com;
access_log/var/log/nginx/example.com-access.log main;
location / {
proxy_pass http://127.0.0.1:8080; # proxy to pylons app
include /etc/nginx/proxy.conf; # see below
}
# static content
location ~ ^/(images|javascript|css|flash|yui|yui-ext|downloads)/ {
root/var/www/public_html;
expires 30d;
}
location = /favicon.ico {
root/var/www/public_html/images;
}
}
# proxy.conf - common to lots of vhosts
proxy_set_headerHost $host;
proxy_set_headerX-Real-IP $remote_addr;
proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
There's other examples on the Nginx wiki.
Regards,
Cliff
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Serving static content
On Mon, 2007-04-30 at 01:09 -0700, voltron wrote: Can one map the /public folder in a Pylons web application to a folder declared for use by a separate web-server? This is a question about your webserver, not Pylons. Simply tell your webserver to serve content from that directory (or any other directory) and refer to the correct location in your templates. Personally I prefer not having static files in the same directory tree as my application. Once in a while, the graphic artists would like to change CSS or image files, the have access to the server root and can upload data in /css and /image folders respectively. For production, one would use a Web server like Apache or Cherokee, and since they are the best at what they do, serving static content fast, it would make sense that all static cont be served from them. I have a mild suspicion this is what everyone does. Is there some preferred basic general setup that can be used? I usually proxy to my Pylons app from Nginx, and tell Nginx to serve static files from a specific directory. In your case, you'd use Apache or Cherokee, so you'll have to read the documentation for those webservers. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylon with Apache
On Sun, 2007-04-29 at 11:21 +0200, Wichert Akkerman wrote: There is also another way of integrating with apache: http://www.rkblog.rk.edu.pl/w/p/mod_wsgi/ When I saw this module, I thought oh, cool and actually (briefly) considered trying to port it to Nginx, but came back to the arguments I outlined here and ultimately decided against it. Proxying is just too dead simple and flexible. It would take demonstrably huge performance gains to change my mind. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons Evaluation -Questions
On Fri, 2007-04-27 at 17:27 -0700, Shannon -jj Behrens wrote: On 4/27/07, Cliff Wells [EMAIL PROTECTED] wrote: Out of curiosity, how is this ugly? This should be mostly handled transparently by the proxy (i.e. sends same sessions to same backend). If one Web server dies, all the users using that Web server lose their sessions. That sucks. It also limits the effectiveness of the load balancer. It can only redistribute *new* users instead of each new request. Ah. Makes sense. I guess reading books *does* help! or b) use a session server (less ugly). And what do you recommend for this? If I had to make the decision today, I'd probably use memcache. mmm. Memcached rocks. I've not seen this approach, so I'm curious (or maybe the proxy acts as a session server, so we're talking about the same thing?). What do you mean the proxy acts as a session server? I don't know of any load balancers who can act as session servers. I wasn't sure exactly what you meant by session server, but now I do. So you are correct. I was thinking perhaps you meant external process that maintains sessions across backends in which case some load balancers do. By the way, this topic is covered nicely in Scalable Internet Architectures and Building Scalable Web Sites. (weird, de ja vu ;) If only I had time to read actual books rather than bug people on the net for answers... Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons Evaluation -Questions
On Sat, 2007-04-28 at 08:07 -0400, Dan wrote: IMHO. I never implemented memcache, but the distributed memory concept is *not* by itself scalable architecture. The key is session data. Typically (as in default Pylons setup) session data is tied to physical hardware... your web server. To make use of memcache, one would first need to implement scalable architecture, such as the 'share nothing' approach. And this is what Memcached does. Simply store your session data in Memcached. Again, I'm not claiming to be an expert on the 'share nothing' architecture, but my understanding is that 'share nothing' stores all data in the database... even session data. But of course, database doesn't have to mean SQL database. Memcached provides a hash in the sky quite ideal for this type of problem. This way, it doesn't matter what web server in your farm takes users requests. They will all ask the database (the db will be your bottleneck) but at least they will *mostly* know how to access and store data. Again, this is exactly what Memcached is meant to do. Memcached can share data transparently across servers and will typically be *much* faster than database access (and much, *much* easier to implement - distributed databases are not fun [or cheap]). If you'll recall, Memcached was developed to help solve LiveJournal's scalability issues, so it's quite well-tested: http://www.linuxjournal.com/article/7451 Also, if your architecture consists of storing your data in a single database, you will certainly *not* scale beyond a certain point. The database itself will become a bottleneck. In fact, if you read the above article, you'll find that Memcached was in fact developed to help remove load from the LiveJournal databases. So the basic point to my post is that scalable architecture is more about theory than specific tools. The theory behind building scalable web applications is a growing subject in system engineering that I find interesting. You can check a decent article about myspace.com struggles at - http://www.baselinemag.com/article2/0,1540,2084131,00.asp I found the articles on scaling Wikipedia interesting, although I can't find the link to them at the moment... Despite the fact that MySpace obviously scales to a large degree, I put little trust in their technical abilities (they can't even do CSS or search properly). I suspect their scalability is largely derived from millions of dollars in investments rather than actual architecture. *Anyone* can scale if they can throw unlimited money at it ;-) 'memcache' is a tool, when applied to a scalable architecture, could provide performance improvements. Distributed information is a cornerstone of a scalable architecture (sessions are simply information in this context). Memcached provides exactly this and is therefore more than just a tool. It's a foundation point for building a scalable architecture. Of course, for most of us, this is interesting but purely theoretical. For most of the sites I do, the required scalability of a Pylons app consists of running multiple instances of the app behind a load balancer on the same server ;-) Of course, the same problems and solutions apply but on a much smaller scale. Planned right, scaling from multiple processes on a single machine to hundreds of processes across multiple machines really is a matter of scale rather than architecture. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylon with Apache
On Sun, 2007-04-29 at 01:42 +, Graham Dumpleton wrote: On Apr 28, 6:40 am, Cliff Wells [EMAIL PROTECTED] wrote: On Fri, 2007-04-27 at 07:36 -0600, Orr, Steve wrote: What are the advantages/disadvantages pros/cons to doing a proxy instead of just usingmod_python? Typically, proxying is: 1. easier to setup thanmod_python 2. easier to upgrade Python (nomod_python/python version issues) Can you elaborate further on what the specific mod_python/python versions issues are? Note that I ask this to learn what the problems supposedly are and why it may be any more problematic than having to recompile any third party C extension modules for Python which you may have also installed into the Python site packages directory. Such feedback would be useful because although people grumble about this and use it as a reason against using mod_python, those same people never actually come over to the mod_python mailing list to describe the problems so that mod_python may if required be improved or so they may be corrected in their understanding as to how things work. I can give you a very specific example as I'll be dealing with it in the next couple of days ;-) A customer has an old Fedora (2 or 3) installation already running lots of stuff under Apache. mod_python (as shipped by Red Hat) is compiled against Python 2.3. Python 2.4 is installed but not used by mod_python. The client now wishes to run a Django application and requires 2.4. Most likely this will mean running two instances of Apache or (more likely), having to run Django as a fastcgi. Personally, I have no problem with running Django as a fastcgi, but it wasn't the client's first choice (and I believe mod_python to be the recommended deployment method for Django). Anyway, I'm not 100% certain there's anything that can be done by the mod_python project to resolve this particular type of issue (unless perhaps it would be possible to run multiple mod_python compiled against different versions of Python on the same Apache instance, but even then, we're still talking about lots of configuration, compiling, etc that simply aren't required for a proxied application). In short, the looser coupling between the webserver and the application that proxying provides gives all the usual benefits one might expect over a fully integrated solution and frankly, there isn't much downside as far as I can tell. The only other problem area is transitioning to a newer version of Python using the same system. That is, where you might want to be able to run applications using different versions of Python. To do this would mean running two distinct instances of Apache on the same box but with different installations of mod_python/Python. Preferably if doing this one should just perhaps use two different hosts. And this is my point: with proxying this isn't even remotely an issue. So except for the two quite specific issues noted above, are your problems perhaps really just an issue of dependency management, something that is going to occur for any software components and not just mod_python itself? It occurs with any tightly coupled software system. Sometimes a tight coupling brings benefits that outweigh the issues you incur, but in this case I simply don't see the benefit of tightly integrating with the webserver. Performance benefits are usually negligible to non-existent over fastcgi or proxying and frankly I'm not sure what other benefits might even be claimed. Any feedback would be most appreciated so the real problems can be understood. Unfortunately when I have tried to dig into such claims in the past, there is usually dead silence, so can never find out what the real problems are so they can be addressed in mod_python if need be. :-( Well, here you have it ;-) Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
RE: Pylon with Apache
On Fri, 2007-04-27 at 07:36 -0600, Orr, Steve wrote: What are the advantages/disadvantages pros/cons to doing a proxy instead of just using mod_python? Typically, proxying is: 1. easier to setup than mod_python 2. easier to upgrade Python (no mod_python/python version issues) 3. doesn't require restarting Apache as often 4. just as fast 5. frees you from having to use Apache at all (other proxy solutions are available that are usually faster and lighter than Apache) Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Session store
On Fri, 2007-04-27 at 17:24 -0700, Shannon -jj Behrens wrote: This topic is covered very nicely in Building Scalable Web Sites and Scalable Internet Architectures. Okay, one more plug for these books and there's going to be a demand for full disclosure ;-) Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: AuthKit using database for users, groups, roles?
On Thu, 2007-03-22 at 18:48 -0400, Chris Shenton wrote: I've written a HOWTO on what I did at http://pylonshq.com/project/pylonshq/wiki/PylonsWithAuthKitDatabase Feedback, sanity checks and corrections welcomed. I'm sure it's far from optimal but hope it will help other folks get started with this common chore. Very minor nit. You specify that the username is unique in the model, but then explicitly test in valid() whether more than one user is returned (which is theoretically impossible). Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Still not working
On Wed, 2007-03-21 at 21:50 +, Jamie wrote: Thanks. Unfortunately I just read your message now after a day of building the x64 version of CentOS. :-( I haven't gotten to the point to where I'm tackling the production version with mod_python. After installing the OS, I added Postgres, Python 2.5, pyscopg2, pylons, sqlalchemy, and mako. Everything seems to be kosher, but now I'm having problem with either the Paste web server or pyscopg2. See this: http://www.initd.org/tracker/psycopg/ticket/127 or if that site isn't working (it was having some issues as I write this): http://72.14.253.104/search?q=cache:gXyPuRIu2YEJ:www.initd.org/tracker/psycopg/ticket/127+psycopg2+x86_64+segfaulthl=enct=clnkcd=3gl=us http://72.14.253.104/search?q=cache:EX0Pb0DZZSoJ:lists.initd.org/pipermail/psycopg/2007-February/005326.html+psycopg2+x86_64+segfaulthl=enct=clnkcd=1gl=us It seems this is an issue wrt Python 2.5 and Psycopg2. You might try falling back to Python 2.4 and see if the problem persists. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Still not working
On Tue, 2007-03-20 at 10:50 -0700, Jamie wrote: Thanks for the suggestions; unfortunately it's still not working. There was nothing in /var/llog/messages, but I disabled selinux anyhow. I'm still getting a file not found error. I beginning to wonder if I have a deeper system issue though. The motherboard in my dev box blew out last week so I put the HDD in an available system. I don't know whether it's because the original had a 32-bit Intel chip and the new one has a 64-bit AMD, but some things have been a bit flaky. Python, for example, was complaining about not being able to find a module that's part of the base package. After recompiling it things worked normally again. I might just wipe it and reload. Keep you posted... Did you do a fresh install on the AMD? If so, did you install the x86_64 or i386 version? Most distros maintain a separate /usr/lib and /usr/lib64 for compatibility and I've had issues with building Python packages on these platforms. In my case I managed to work around it by simply getting rid of the 32-bit /usr/lib and renaming the /usr/lib64 to /usr/lib. The problem seems to be due to the fact that certain Python modules get stuck in lib64 and some in lib and Python gets confused. Switching to pure 64 bit in this way will mean you can't run certain binary-only packages (Flash for one) but won't hurt much else. As an aside, unless you've got over 4GB of RAM, you'll find that 64bit mode will make your machine considerably slower (and less compatible) so I'd highly recommend just sticking with the i386 version unless you've got lots of RAM. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: formbuild questions
On Tue, 2007-03-20 at 09:16 +, James Gardner wrote: The relevant sections of the manual (http://formbuild.org/docs/manual.html) to get you started are I seem to recall (perhaps incorrectly) that formbuild was being deprecated/discontinued/merged with another project. Is this the case or is that... um, remember stuff... thing... I have in my head failing me? Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
On Sat, 2007-03-10 at 13:38 -0800, iain duncan wrote: Hi folks, I am just wetting my feet with pylons. I am curious whether anyone on here has experience integrating desktop apps with pylons projects, and if so, would they care to share opinions on feasability, when it is worth, how it went, how they did so? I discussed this on the TurboGears-dev list a while back (and Pylons should be no different in this regard): A while back I built a TurboGears app that utilized XRC (see http://wiki.wxpython.org/index.cgi/UsingXmlResources) templates that wxPython can render as GUI elements. The main application (compiled as an .exe) was little more than a bootstrap loader that downloaded a zipfile of Python modules from the TG server and then rendered each page of the GUI via XRC. Aside from the initial downloading of the Python modules, it worked more or less like a web application: whenever a new page was needed, it fetched the XRC description from the server and rendered it. It worked great, giving all the advantages of a web app (centralized administration and ubiquitous access) and all the benefits of a GUI app (sophisticated UI controls and local system integration). Further, because all the database access was done via normal HTTP (I used pycurl), the GUI app was well-insulated from the underlying implementation and much of the server-side code was reusable for an actual web application as well (the GUI served as the administrative interface for controlling a public-facing website). Were I to do it again (and I'm sure I will) I'd probably use http://techgame.net/projects/Framework/wiki/ rather than plain XRC, however. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
On Mon, 2007-03-05 at 22:29 +0100, Christoph Haas wrote: But installing anything using easy_install - and be it just into /usr/local - is chaotic and hard to control. easy_install cannot even remove software properly. So I don't think I would want anything than a binary deb package on my system. Just as a side note to Shannon Behrens who said We're on Ubuntu, and we just use eggs. If you really just install eggs instead of proper binary packages then your Ubuntu package management will get into trouble in no time. (For those not familiar with it: Ubuntu is a sister project of Debian and uses the same package format.) Why is this so? I don't use Ubuntu (rather Gentoo and Fedora), but the problem is mostly the same. Frankly I tend to avoid all distro-provided Python packages and use easy_install exclusively. I think there might be issues mixing the two methods, but I'm not entirely clear how selecting easy_install *exclusively* over the system package manager makes anything worse. I will note that there are two main reasons I prefer easy_install: 1) The packages provided by most distros tends toward the stale side and tend to be far less inclusive than the Cheeseshop. This means that *no matter what* I'd be forced to use easy_install on some packages at some point. If anything is going to cause issues, it's *mixing* easy_install with apt/rpm/emerge/etc. Were I to choose using the system package manager I'd have a rather smallish selection of slightly (or badly) out-of-date packages with no obvious benefit in exchange for this sacrifice. Given that this is the case, selecting to use easy_install exclusively appears to be a no-brainer. 2) For my specific environments, I utilize user-owned site-packages directories (which helps with maintaining version compatibility for deployed applications and allows users to install/maintain their own required packages). This is probably not possible using the system packaging tools. I'll add that while it's true that easy_install cannot remove packages properly, doing so manually is hardly problematic (remove the .egg and its corresponding entry from easy_install.pth). This doesn't resolve dependency issues, but frankly those aren't nearly as much of an issue with Python as they are at the OS level (simply by nature of Python's more limited scope and influence on the system at large). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
On Mon, 2007-03-05 at 23:42 +0100, Piotr Ozarowski wrote: [Cliff Wells, 05.03.2007] On Mon, 2007-03-05 at 22:29 +0100, Christoph Haas wrote: But installing anything using easy_install - and be it just into /usr/local - is chaotic and hard to control. easy_install cannot even remove software properly. So I don't think I would want anything than a binary deb package on my system. Just as a side note to Shannon Behrens who said We're on Ubuntu, and we just use eggs. If you really just install eggs instead of proper binary packages then your Ubuntu package management will get into trouble in no time. (For those not familiar with it: Ubuntu is a sister project of Debian and uses the same package format.) Why is this so? You can install your Pylons app. and forget about dependencies for next 2 years. Package maintainers will fix all bugs in related packages. There is almost zero chance of that happening in the Python world, no matter who's working on it. In fact, if I install a Pylons app written around Pylons 0.9.x, it's almost guaranteed that letting the system package manager update Pylons will break that app at some point in the not-so-distant future (in fact this exact issue around TurboGears was the very reason I moved solely to easy_install). This problem isn't Python-specific either. You'll note that almost all Ruby users use gem to install packages as well. I've also found that PHP does better when using PEAR for the most part. The single exception I've found where the system packaging tools do a better job is when there are C extensions involved (and hence a reliance on system libraries and a dependency tree that might fork outside the realm of Python and easy_install). Sure, developers like ez_install. System administrators don't! That's odd, because I do equal parts of both and greatly prefer easy_install. On my shared hosting boxes, I can use easy_install to maintain specific versions of Python packages as required by specific applications for specific users, something not easily doable (or doable at all) using the system packaging tools. Note that I'm not suggesting that for *some* people using the system tools might not be preferable to easy_install nor that pursuing the packaging of Python libraries and apps as debs/rpms/ebuilds or whatever is a waste. I am, however, contesting the blanket assertions that using easy_install leads to chaos (it doesn't) or that system administrators prefer the system tools over easy_install (this is pure speculation based on the assumption that the sysadmin is clueless about easy_install/gems/PEAR/cpan/et al). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deploy applications and templates
On Fri, 2007-02-23 at 11:03 -0800, Jose Galvez wrote:
you need to edit the setup.py file to include your templates. Change
the package_data line to look like package_data={'dmetrix':
['i18n/*/LC_MESSAGES/*.mo', 'templates/*.*']} this will include all
your template files.
Of course this precludes the user editing the templates. A more general
solution might be to make the app take a configuration option pointing
to the template root and bundle the templates separately.
This is assuming you want the user to be able to customize the templates
at all.
Regards,
Cliff
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: QuickWiki tutorial doesn't work for me. Error in paster make-config QuickWiki test.ini
On Mon, 2007-02-19 at 23:14 +, Valery wrote: File /usr/lib/python2.4/site-packages/Cheetah-2.0rc7-py2.4-linux- i686.egg/Cheetah/Parser.py, line 1445, in parse self.assertEmptyOpenDirectivesStack() File /usr/lib/python2.4/site-packages/Cheetah-2.0rc7-py2.4-linux- i686.egg/Cheetah/Parser.py, line 2554, in assertEmptyOpenDirectivesStack raise ParseError(self, msg=errorMsg) Cheetah.Parser.ParseError: Some #directives are missing their corresponding #end ___ tag: cache Line 45, column 18 Line|Cheetah Code |- 42 |# WARNING: *THE LINE BELOW MUST BE UNCOMMENTED ON A PRODUCTION ENVIRONMENT* 43 |# Debug mode will enable the interactive debugging tool, allowing ANYONE to 44 |# execute malicious code after an exception is raised. 45 |set debug = false Believe it or not, this probably has nothing to do with Pylons. Rather, because Cheetah supports the python.templating_engines entry point, Cheetah is gets imported automatically whether you use it or not and apparently your version of Cheetah is broken. Try upgrading or uninstalling Cheetah. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: QuickWiki tutorial doesn't work for me. Error in paster make-config QuickWiki test.ini
On Tue, 2007-02-20 at 00:12 +, Valery wrote: Hi Cliff Believe it or not, this probably has nothing to do with Pylons. Rather, because Cheetah supports the python.templating_engines entry point, Cheetah is gets imported automatically whether you use it or not and apparently your version of Cheetah is broken. Try upgrading or uninstalling Cheetah. uninstalling sounds more radical for me... upgrade means that the version of Cheetah automatically downloaded an hour ago was somehow out-of-date? you probably mean upgrade to the development version. how to upgrade then? I am newbie in Python's world :) Actually the latest release in the Cheese shop is 1.0. and you've installed 2.0rc7. I'm not sure how you installed, but I suggest you remove your existing version and reinstall using easy_install Cheetah which should work fine. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Fast Python webserver
On Sun, 2007-02-18 at 17:50 +, James Gardner wrote: Unless I've set something up very wrong, that means that there is about a 1ms overhead using Nginx as a proxy compared to doing the requests directly but that using HTTP is about 5 times faster than using FastCGI. Should I be using a different version of Nginx? 0.4.13 is pretty old, but I'm still surprised by that amount of overhead. Maybe you could try with the latest (0.5.12) version? I would say though that Nginx is very easy to setup and I do like it, even if the FastCGI setup doesn't seem faster than the HTTP setup with Pylons. Most of the benchmarks I've seen (which is only a couple) have shown FastCGI on Nginx to be slightly faster than proxying, although by a very small amount. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Fast Python webserver
On Sun, 2007-02-18 at 12:20 -0800, Bob Ippolito wrote: However, proxying is a lot easier to set up than FastCGI. Absolutely. That's what I always use. I doubt the small performance gain is going to add up to much in the way of scalability anyway ;-) What I typically use is a small cluster of Pylons servers proxied to by Nginx, which is something else not as easily done with FastCGI. I'm sure there's things that can be done to paste.httpserver to make it come closer to FastCGI in performance. Maybe. I'm going to be investigating fapws (and perhaps CherryPy's WSGI server as well) to see if there's any significant gain by using those rather than paste.httpserver (although I suspect most of the overhead is in the framework and application, not the HTTP server itself, so even significant gains in HTTP performance might not add up to much overall). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Fast Python webserver
On Sun, 2007-02-18 at 23:42 +, James Gardner wrote: I've heard the same rumour in other places too though actually, particularly related to rails but also with Pylons eg: http://www.rkblog.rk.edu.pl/w/p/pylons-benchmark-various-servers/ This is the benchmark I remember seeing, although I've heard others mention similar results. OK, I was testing on localhost. I don't think testing on localhost is ever going to give accurate results since the client load is added to the server load on the same machine. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: ANN: AuthKit 0.3.0pre4
On Fri, 2007-02-16 at 15:02 +, James Gardner wrote: I'd encourage anyone who is currently using the dev version to upgrade to 0.3.0pre4 so we can see if there are any issues before 0.3.0 is formally released in a couple of weeks time. It fails for me with: AuthKit-0.3.0pre4-py2.4.egg/authkit/authenticate/__init__.py, line 125, in _get_value raise AuthKitConfigError( authkit.authenticate.AuthKitConfigError: The required option 'authkit.method' was not specified However I do have authkit.method = forward in my .ini file (and this worked with the prior release). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons, genshi and xml
On Tue, 2007-02-13 at 17:00 -0800, Ben Bangert wrote: On Feb 13, 2007, at 2:11 PM, Matt Good wrote: Yes, this was based on the Kid engine provided by TurboGears which uses module-style names to load templates. Last I checked Pylons also expected all template engines besides Myghty and Mako to use this convention. I plan to make the Genshi plugin usable with file paths as well, but of course I need to be sure to allow for backwards compatibility. In the Mako plugin, I've set it up so that if you have a / in the template name, it assumes you're doing full paths. Thus if it sees 'dir.tmpl' it assumes its dot notation template, and if its '/dir/ tmpl.html' it assumes its a path due to the /. If the Genshi template does this toggling as well, I'll add Genshi to the template engines that don't have their path 'touched' before it goes to the template engine. I'm not thrilled to be hacking around the TG spec, clearly a new spec is needed but as there doesn't seem to be any traction or clear leader of that spec and its evolution this should work decently in the meantime. Actually, the TG spec is completely superfluous. You can use / rather than . and it will work just fine. I just removed support for dotted path notation from Breve as it causes problems (e.g. paths with dots in them) and provides nothing in return. If you don't have a large userbase of people expecting dot notation to work, I'd get rid of it now before you do. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
paste recursive
Hi, I've been toying with the notion of having templates have more control over how they are rendered by allowing them to request fragments from an application. I did a simple test implementation that simply used urllib2 to call back into the Pylons application as a completely separate request, and this works great except that it's obviously inefficient. Of course, in the apparent tradition of Ian thought of it first, I stumbled across this: http://pythonpaste.org/module-paste.recursive.html which would seem to be exactly what I'm looking for: a way to request fragments from a WSGI app in an efficient manner. This brings me to my questions. Can this be used with Pylons? If so, how? As middleware in config/middleware.py? I'm afraid I'm a bit hazy on how this works. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: [Paste] Paste's HTTP server thread pool (reliability)
On Fri, 2007-02-02 at 16:03 -0600, Ian Bicking wrote: Shannon -jj Behrens wrote: The specific project we're working on involves fetching other URLs, which is something that can block in awkward ways. We have some ideas to avoid that (probably not performing the subrequests in the request thread), but even so I would like some additional places where we can catch problems. Generally when something goes wrong I really don't like the current behavior, which is that there's no way to notice until the whole server stops responding, and no resolution except restarting the server. This doesn't really address the larger issue, but I've found that using Twisted for such things works great. I've never really been able to manage writing an entire application in Twisted but writing simple apps that do things like fetch a bunch of URLS and republish the results of that as a local service is remarkably simple and robust. Also, unlike much of Twisted, there tends to be lots of examples for doing such things lying about the web. A few months ago I wrote an RSS aggregator in Twisted that would fetch remote feeds and republish them as a local service that a TurboGears app could then quickly and reliably fetch from. This nicely sidesteps blocking threads in your Paste/Pylons/CherryPy server. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons powered-by logo
On Mon, 2007-01-22 at 15:19 +, ToddG wrote: http://pylons.tgtg.org/powered/ Was this not already on the Wiki? I downloaded one of these for the Breve site a few weeks ago following link from http://pylonshq.com/project/ under Other Wiki Areas/Propaganda Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: how to build a portlet style site?
On Wed, 2007-01-17 at 12:55 +, James Gardner wrote: Hi Paul, I'm developing a new templating system called art which handles this particular case. Instead of using a controller to call a template and display the result, the template effectively defines which content it requires and calls the different controllers (called plugins in art) automatically. The individual plugins can run on multiple servers so that content can be pulled in from remote locations and all the fetching is done in parallel with threads so performance is pretty good. I was looking at the W3C docs on XInclude (which, like most W3C docs, aren't terribly enlightening) and this sounds a bit like that (Genshi supports that particular feature, BTW). Any particular differences with XInclude? I've been planning on adding a similar feature to Breve, but am interested in other people's ideas on particulars. Also, since you can pull plugins from different servers, have you considered the implications with regard to Javascript? It seems there might be some security implications (or more likely, security restrictions) that would affect Javascript that is pulled from different servers (although I expect simply documenting such restrictions would be adequate). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: ANN: Breve - Pylons-compatible template engine
Just a quick update: I've fixed a handful of bugs and added a feature or two, and most importantly, Breve is now in the Cheese Shop so it can be easy_installed. Regards, Cliff Cliff Wells wrote: Hi all, It's not 100% finished (there's a small todo list on the site), but I doubt there will be any breaking changes coming any time soon. Breve is a Stan-like template engine that works with any Buffet-compatible framework (Pylons, TurboGears, etc). http://breve.twisty-industries.com/ Please feel free to try it out and email me with feedback. The docs on the site are slightly more up-to-date than those included with the source. There's Pylons-specific notes on the download page. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
template engines and configuration data
Greetings, So having finished my first iteration of Breve, I've come across a glaring incompatibility between how TurboGears and Pylons interact with template engines: specifically how configuration information is passed into the template. It seems TurboGears (which more or less defines this API) passes in configuration data as a function which can be called to fetch specific configuration data, whereas Pylons passes in a dictionary. Further, TurboGears passes this information in the render() method while Pylons passes it in __init__(). For example: # TurboGears: def __init__ (... ): ... def render ( ... ): value = self.get_extra_vars ( )[ 'std' ][ 'config' ]( 'breve.foo' ) # Pylons: def __init__ ( ... ): for k, v in options.iteritems ( ): if k.startswith ( 'breve.' ): breve_opts [ k [ len ( 'breve.' ): ] ] = v def render ( ... ): ... Personally I prefer how Pylons does it (more efficient to pass at template instantiation, more flexible to get an iterable than a function, and not as seemingly complex), but the real issue is that it requires special-case code in the template engine's Buffet adapter which is just plain wrong. I'd rather have one mildly bad API than two incompatible ones that must both be supported. Being passed the values at different times isn't an insurmountable obstacle (in my own code I simply always delay until the render() method is called to fetch them regardless of when they are passed), but having to fetch them two completely different ways is pretty annoying. I've written to Christian Dowski (Buffet's author) regarding this issue, but ultimately a decision is going to require framework support and I'd like to hear any thoughts on the matter from people who might be able to help resolve it. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
ANN: Breve - Pylons-compatible template engine
Hi all, It's not 100% finished (there's a small todo list on the site), but I doubt there will be any breaking changes coming any time soon. Breve is a Stan-like template engine that works with any Buffet-compatible framework (Pylons, TurboGears, etc). http://breve.twisty-industries.com/ Please feel free to try it out and email me with feedback. The docs on the site are slightly more up-to-date than those included with the source. There's Pylons-specific notes on the download page. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Alternate template systems, Buffet, conflicts with TurboGears, and probably other stuff [was Re: The Myghty Philosophy]
Shannon -jj Behrens wrote: By the way, before this thread gets out of control, I strongly believe templating engines are a matter of engineering taste. Pick one you (and your team) like, and let other developers pick ones they like. Pylons doesn't tie you to any of them. Speaking of, I'm a bit curious about the differences between Buffet and the Buffet derivative in Pylons. I've just finished a new templating system and am going to have it working with Buffet/CherryPy/TurboGears, but I'd like to have it work with Pylons too, if at all possible. I looked over the source for Buffet in Pylons and it appears the main difference is the import of some values from the pylons module (although I was just a bit thrown by having the Myghty plugin tossed in there as well - shouldn't that be in a separate module?). One thing that concerns me is if there will be any conflict for people with both TurboGears and Pylons installed... they both use the python.templating.engines entry point. I had the following in my setup.py: entry_points = ''' [python.templating.engines] breve = breve.plugin.buffet:BreveTemplatePlugin pylonsbreve = breve.plugin.pylons:BreveTemplatePlugin ''' and this would cause TurboGears to crash with an error appearing to relate to the Pylons version (although the Pylons version imports just fine from the interactive prompt) =( Anyway, any advice, suggestions, pointers, rtfms, et al appreciated. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
