Re: Deprecate FCGI support in Django 1.7

On Tue, Aug 6, 2013 at 9:40 AM, Andre Terra wrote: > Assuming a UNIX environment. In Windowsland, nginx is still one of the best > alternatives. I meant use those _behind_ NginX. neither is really good as an external-facing HTTP process. -- Javier -- You received this

Re: Deprecate FCGI support in Django 1.7

On Tue, Aug 6, 2013 at 10:18 AM, Javier Guerra Giraldez wrote: > On Tue, Aug 6, 2013 at 6:28 AM, VernonCole wrote: > > I had come the the conclusion that FastCGI was the only way > > > behind NginX, the best two options seem to be uWSGI and gunicorn. >

Re: Deprecate FCGI support in Django 1.7

On Tue, Aug 6, 2013 at 6:28 AM, VernonCole wrote: > I had come the the conclusion that FastCGI was the only way behind NginX, the best two options seem to be uWSGI and gunicorn. personally, I like uWSGI, but both are quite performant and low-resource. -- Javier -- You

Re: Deprecate FCGI support in Django 1.7

Let me second the need for a good "How To" document on deployment. As a neophyte django user I suddenly felt very lost last week. After several months of development, the ADO interface to the Microsoft SQL server from Linux is working (it still needs some tuning, but the data does go in and

Re: Deprecate FCGI support in Django 1.7

Is there a consensus on the project that'll be created to handle this outside of Django? Would be nice to have something to point people to when closing Trac tickets for FastCGI. On Wednesday, July 24, 2013 5:56:45 AM UTC-4, Tom Evans wrote: > > On Sun, Jul 21, 2013 at 8:28 AM, Some Developer

Re: Deprecate FCGI support in Django 1.7

On Sun, Jul 21, 2013 at 8:28 AM, Some Developer wrote: > On 21/07/2013 05:08, Curtis Maloney wrote: >> >> I wasn't aware there was a particular performance issue, but I'll >> certainly keep it in mind. > > > Take a look at this: > >

Re: Deprecate FCGI support in Django 1.7

Well, mostly to indicate it's primary focus is on providing a FastCGI server for Django. I'm quite happy to keep it app agnostic, and be a general FastCGI->WSGI publisher... On 24 July 2013 15:04, Joe Tennies wrote: > Is there a specific reason to call this

Re: Deprecate FCGI support in Django 1.7

Is there a specific reason to call this "django-fastcgi"? I think it should most likely be a generic wsgi to fastcgi binding, right? Or is this project mainly the django management commands? On Jul 22, 2013 8:07 PM, "Curtis Maloney" wrote: > Well, having started

Re: Deprecate FCGI support in Django 1.7

Here's a ticket and pull request for the deprecation. On Tuesday, July 23, 2013 1:19:28 AM UTC-4, Some Developer wrote: > > On 23/07/13 02:07, Curtis Maloney wrote: > > Well, having started looking over

Re: Deprecate FCGI support in Django 1.7

On 23/07/13 02:07, Curtis Maloney wrote: Well, having started looking over the flup source, I can see a lot of useful code to crib, as well as a few critical path bits that can be optimised [without even reducing readability!] So, if you feel like helping out with django-fastcgi ... I'm happy

Re: Deprecate FCGI support in Django 1.7

Well, having started looking over the flup source, I can see a lot of useful code to crib, as well as a few critical path bits that can be optimised [without even reducing readability!] So, if you feel like helping out with django-fastcgi ... I'm happy for the help :) -- Curtis On 23 July

Re: Deprecate FCGI support in Django 1.7

On 22/07/13 10:00, Russell Keith-Magee wrote: The hope is to start accelerating the release cycle slightly; however, this also depends on someone actually doing the work :-) Sounds good. I'd love to start helping with Django myself but I feel a bit lost when it comes to useful things to do.

Re: Deprecate FCGI support in Django 1.7

> To anyone else reading this thread who is still wanting FastCGI I am willing > to help with a third party solution if something is going to come together. > Based on the normal Django release cycle I'd expect 1.7 to be out in either > Q4 this year or Q1 next year so something needs to be done

Re: Deprecate FCGI support in Django 1.7

On Mon, Jul 22, 2013 at 4:48 PM, Some Developer wrote: > On 22/07/13 05:47, Russell Keith-Magee wrote: > >> Based on the feedback from this thread (and the fact that multiple core >> devs, including a BDFL have weighed in), I think it's safe to say that >> the decision

Re: Deprecate FCGI support in Django 1.7

On 22/07/13 05:47, Russell Keith-Magee wrote: Based on the feedback from this thread (and the fact that multiple core devs, including a BDFL have weighed in), I think it's safe to say that the decision has been made. The only question at this point is how long it takes before someone commits the

Re: Deprecate FCGI support in Django 1.7

On Mon, Jul 22, 2013 at 12:21 PM, Some Developer wrote: > On 14/07/13 20:17, Florian Apolloner wrote: > >> Hi, >> >> I'd like to get rid of everything FCGI-specific in Django sooner or >> later (rather sooner). Flup isn't maintained since a long time and there >> is no

Re: Deprecate FCGI support in Django 1.7

On 14/07/13 20:17, Florian Apolloner wrote: Hi, I'd like to get rid of everything FCGI-specific in Django sooner or later (rather sooner). Flup isn't maintained since a long time and there is no ticket tracker to report stuff. Graham pointed out that if someone wants to use FCGI they can use

Re: Deprecate FCGI support in Django 1.7

My understanding was Django is a WSGI application, and as such its role is to process requests handed to it. It isn't the server as such. It's the role of a WSGI publisher to accept requests and pass them on to an appropriate handler. So, uWSGI, gunicorn, flup and mod_wsgi as the Publishers we

Re: Deprecate FCGI support in Django 1.7

On Sun, Jul 21, 2013 at 11:39 AM, Juan Luis Boya wrote: > * An asynchronous server may be attending many client connections at a time > for each worker thread. Concurrency is achieved within the thread using an > application specific dispatcher. In an asynchronous server, there

Re: Deprecate FCGI support in Django 1.7

> Juan, technically Django isn't a server at all... > Django is a web application framework whose operation consists on waiting for HTTP requests from the network (encapsulated with WSGI) and replying each one of them with a HTTP response. Call it what you want. > whether it's sync, async,

Re: Deprecate FCGI support in Django 1.7

On 21/07/2013 05:08, Curtis Maloney wrote: I wasn't aware there was a particular performance issue, but I'll certainly keep it in mind. Take a look at this: http://www.peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi I've probably already said it but if you want some help with this project I'd be

Re: Deprecate FCGI support in Django 1.7

On 21 July 2013 02:30, Some Developer wrote: > On 20/07/2013 14:02, Curtis Maloney wrote: > >> I'm more or less building atop flup as it is, however I plan to shed >> anything not related to FastCGI. >> >> For me it's a chance to get down and dirty with raw protocols

Re: Deprecate FCGI support in Django 1.7

Juan, technically Django isn't a server at all... whether it's sync, async, multi-threaded, multi-process, or a mix of any of them is up to the wsgi publisher used. Take, for example, gunicorn, which can be any of the above, with options to plug in others when they're thought up. -- Curtis On

Re: Deprecate FCGI support in Django 1.7

> If you really want to get down and dirty with raw protocols have you > considered an implementation that used epoll or kqueue for the > networking? Combined with nginx as the front end HTTP server it should > (theoretically) result in a huge increase in performance. > > Basing the work on

Re: Deprecate FCGI support in Django 1.7

No FastCGI isn't a bad protocol. But it's not recommand to deploy Python Application's with FastCGI. FastCGI is good for deploying PHP or even sometimes Golang (but here, the plain Webserver is better). But! FastCGI is a low level protocol and WSGI tries to get rid of that. Flup is just a

Re: Deprecate FCGI support in Django 1.7

I'm more or less building atop flup as it is, however I plan to shed anything not related to FastCGI. For me it's a chance to get down and dirty with raw protocols again... I do agree there is a shorter path to just applying Django's "fixes" to a fork of flup. -- Curtis On 19 July 2013 22:14,

Re: Deprecate FCGI support in Django 1.7

On 20/07/13 13:24, Christian Schmitt wrote: No FastCGI isn't a bad protocol. But it's not recommand to deploy Python Application's with FastCGI. FastCGI is good for deploying PHP or even sometimes Golang (but here, the plain Webserver is better). But! FastCGI is a low level protocol and WSGI

Re: Deprecate FCGI support in Django 1.7

On 20/07/13 12:32, Christian Schmitt wrote: I would recommand to remove FastCGI. That's the thing i love with the Python Community. Remove depracted or obsolete things. The thing is, there are way more important things to do, than supporting a 'depracted' way to deploy. And it's really not that

Re: Deprecate FCGI support in Django 1.7

I would recommand to remove FastCGI. That's the thing i love with the Python Community. Remove depracted or obsolete things. The thing is, there are way more important things to do, than supporting a 'depracted' way to deploy. And it's really not that hard to get mod_wsgi with a httpd

Re: Deprecate FCGI support in Django 1.7

> > For those who are keen to keep support for FastCGI, would you be > interested in helping me develop/maintain a Pure Python > FastCGI->WSGI(Django-specific) publisher package? > That exists and it's called flup. The code base is relatively small. What about simply forking it to something

Re: Deprecate FCGI support in Django 1.7

On Friday, July 19, 2013 12:53:48 AM UTC+2, Javier Guerra wrote: > i think several people like to use gunicorn for http-wsgi, if it (or > something similar: flask? wep.py?, werkzeug?) supports fcgi, it could > be the recommended fcgi solution. > flask, webpy, werkzeug: all of those use flup.

Re: Deprecate FCGI support in Django 1.7

On 19/07/13 01:31, Curtis Maloney wrote: For those who are keen to keep support for FastCGI, would you be interested in helping me develop/maintain a Pure Python FastCGI->WSGI(Django-specific) publisher package? I agree it's valuable to have, as many have said [and I believe all have agreed]

Re: Deprecate FCGI support in Django 1.7

For those who are keen to keep support for FastCGI, would you be interested in helping me develop/maintain a Pure Python FastCGI->WSGI(Django-specific) publisher package? I agree it's valuable to have, as many have said [and I believe all have agreed] but to keep it in core is unmaintainable.

Re: Deprecate FCGI support in Django 1.7

On Thu, Jul 18, 2013 at 5:30 PM, Juan Luis Boya wrote: > uWSGI + FastCGI: We should have nice docs about this. as others have previously said, uWSGI isn't viable for everybody. is there any other pure-python fcgi-wsgi server with reasonable performance? i think several

Re: Deprecate FCGI support in Django 1.7

I'm against deprecating FastCGI at all because it's the only cross platform, language independent, minimally scalable standard for deploying web applications in web servers (apart from HTTP proxy). WSGI may be nice to Python developers, but the world doesn't end after Python. Not all web

Re: Deprecate FCGI support in Django 1.7

On 15 juil. 2013, at 23:45, Jacob Kaplan-Moss wrote: > Let's start FCGI (and the others) down the path to deprecation. If there's > truly a community that finds value in these things -- and frankly I think > that once they try modern options they'll quickly switch and never

Re: Deprecate FCGI support in Django 1.7

On Mon, Jul 15, 2013 at 6:45 PM, Jacob Kaplan-Moss wrote: > > Let's start FCGI (and the others) down the path to deprecation. If there's > truly a community that finds value in these things -- and frankly I think > that once they try modern options they'll quickly switch and

Re: Deprecate FCGI support in Django 1.7

On Mon, Jul 15, 2013 at 4:31 PM, Florian Apolloner wrote: > Also, if we move it outside of django-core we can send a good signal that > FCGI in Django is basically "Use at your own risk" (which it is already if > you ask me). > This, for me, is the key: anything that's not

Re: Deprecate FCGI support in Django 1.7

On Monday, July 15, 2013 9:55:51 PM UTC+2, Aymeric Augustin wrote: > > - Django's core developers don't use FCGI — at least, I don't know any > active core dev who does. > I do, but with a patched flup and a patched suexec and what else, so I am hardly a typical usecase; and I am in the

Re: Deprecate FCGI support in Django 1.7

On Monday, July 15, 2013 6:20:45 PM UTC+2, Some Developer wrote: > > What about SCGI and AJP support? Is that going? > Yes, it's either all or nothing. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and

Re: Deprecate FCGI support in Django 1.7

On 15/07/2013 13:37, Florian Apolloner wrote: On Monday, July 15, 2013 9:38:33 AM UTC+2, Some Developer wrote: This would be a mistake in my opinion. Based on what? Django would still support FCGI via flup like it does now, we'd just get rid of the management commands you usually can't

Re: Deprecate FCGI support in Django 1.7

remember that on "shared hosts" we do not have option to use, explicity http ports, like examples from [1]. we do not have root access, nor http.conf access for apache2/root configs. when we hare dedicated server it is easy run app with django. on shared host, all config for running django fcgi

Re: Deprecate FCGI support in Django 1.7

On 15/07/13 16:10, Florian Apolloner wrote: On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote: If you're suggesting to move the FastCGI code into a separate app: +1 I'd have just dropped it, but yes we can move it out; although someone else will have to step up to continue

Re: Deprecate FCGI support in Django 1.7

On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote: > > If you're suggesting to move the FastCGI code into a separate app: +1 > I'd have just dropped it, but yes we can move it out; although someone else will have to step up to continue maintaining it (if there is a need to

Re: Deprecate FCGI support in Django 1.7

On 14.07.2013, at 21:17, Florian Apolloner wrote: > Hi, > > I'd like to get rid of everything FCGI-specific in Django sooner or later > (rather sooner). Flup isn't maintained since a long time and there is no > ticket tracker to report stuff. Graham pointed out that if

Re: Deprecate FCGI support in Django 1.7

On 15/07/13 13:13, mjl Martin J. Laubach wrote: Is there actually a problem with flup? Not being maintained doesn't mean it's totally broken and it obviously works just fine for a lot of folks? mjl I use it myself and haven't had any issues with it either I was just responding to

Re: Deprecate FCGI support in Django 1.7

On Monday, July 15, 2013 7:07:08 AM UTC+2, Russell Keith-Magee wrote: > > I'm not arguing that FastCGI is a good option, just that it's prevalent. > And if we're going to stop supporting it, we need to be aware of who we're > cutting off. > We won't cut anything off (maybe aside from the

Re: Deprecate FCGI support in Django 1.7

If it were just Hostgator that was the problem, that might be a worthwhile approach. But that's not the true scope of the problem. We're talking about every hosting provider in the "$5 per month" hosting category that currently supports PHP, and provides FCGI as the fastest way they can support

Re: Deprecate FCGI support in Django 1.7

Has anyone thought to contact HostGator and see how they would react to Django dropping FastCGI and/or whether they would be willing to support a WSGI option. Regards, Michael Manfre On Mon, Jul 15, 2013 at 12:44 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On Mon, Jul 15,

Re: Deprecate FCGI support in Django 1.7

On Mon, Jul 15, 2013 at 10:06 AM, Curtis Maloney wrote: > As much as I recognise FastCGI is pretty much a dead technology in the > Python world, for people stuck with cPanel sites like HostGator, it still > appears to be, pretty much, the only option. > > And

Re: Deprecate FCGI support in Django 1.7

As much as I recognise FastCGI is pretty much a dead technology in the Python world, for people stuck with cPanel sites like HostGator, it still appears to be, pretty much, the only option. And installing uWSGI there is simply not an option there. So unless there's a pure python FastCGI -> WSGI

Re: Deprecate FCGI support in Django 1.7

i start 2 months ago using fcgi inside an shared host (hostgator.com) and after lots of tries with wsgi only using fcgi was worked with apache2. but i will read and learn about uwsgi and try this. my app use version 1.6a of django is 1.6b worked using python 2.6. because parts of my app is with