[ANNOUNCE] Django 1.7 release candidate 1

[James Bennett]

We're closing in on the final Django 1.7 release, so it's release-candidate time!

Details are up on the Django project blog:

https://www.djangoproject.com/weblog/2014/jun/26/17rc1/

[cercatrova2]

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAL13Cg9mu6To35mC2_wCyn0NHwz7htD%3D8vfnHnWL_OO1NkmAqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

"FastCGI support via the runfcgi management command will be removed in Django 1.9. Please deploy your project using WSGI."

Why does the documentation *persist* in confusing FastCGI with WSGI?

FastCGI is a protocol and WSGI is an API. One can deploy a WSGI application over FastCGI and that is exactly what a FastCGI-to-WSGI adapter like flup does (flup is what runfcgi is written for). There are so many clarifications about this out there, including at least one by the author of mod_wsgi (http://stackoverflow.com/questions/1747266/is-there-a-speed-difference-between-wsgi-and-fcgi)

And it seems that the point made in the developer thread about deprecation being unwise was simply ignored and intentionally misunderstood (https://groups.google.com/forum/#!topic/django-developers/oGmD8LvLTPg "Deprecate FCGI support in Django 1.7").

My case is just one example - there's an apache/mod_python/python2 application that I can't touch, so to run something on apache with python3 I need mod_fastcgi/mod_fcgi and flup. Mixing mod_python/python2 with mod_wsgi/python3 doesn't work even in daemon mode.

[James Bennett]

On Fri, Jun 27, 2014 at 3:12 AM, cercatrova2 <cerca...@gmail.com> wrote:

"FastCGI support via the runfcgi management command will be removed in Django 1.9. Please deploy your project using WSGI."

Why does the documentation *persist* in confusing FastCGI with WSGI?

This does not confuse them (if it were confusing them, it would assume that FastCGI and WSGI are identical).

And it seems that the point made in the developer thread about deprecation being unwise was simply ignored and intentionally misunderstood (https://groups.google.com/forum/#!topic/django-developers/oGmD8LvLTPg "Deprecate FCGI support in Django 1.7").

I don't see anyone ignoring or intentionally misunderstanding in that thread.

The "runfcgi" command and its supporting code just implements a FastCGI<->WSGI bridge using flup. That's convenient for cases where FastCGI is the only deployment option, but it does come at a significant cost: flup appears to be abandonware, and the flup-based bridge has generated a lot of bugs and maintenance headaches. That cost was deemed the bigger issue, and so Django will no longer have a built-in FastCGI<->WSGI bridge based on flup.

This doesn't mean that Django can't be deployed using FastCGI, of course; it just means that someone else needs to provide the bridge from FastCGI to WSGI, because going forward Django will only support speaking WSGI, and will not include its own bridge to let it pretend to speak FastCGI or other gateway protocols. And in that thread several people showed interest in starting and maintaining a third-party package to provide that bridge. If FastCGI is a requirement for you, your best course is likely to follow up on that effort.

[cercatrova2]

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAL13Cg_sXKbHmwvp-JnihBqGGwq3wxoB8zZB1behdcQ%3DpPTB7w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Come now. When you say "FastCGI support via the runfcgi management command will be removed in Django 1.9. Please deploy your project using WSGI." it implies that they are mutually exclusive. They are not. I'm using FastCGI and I've deployed my project using WSGI.

It's like how the doc states "Although WSGI is the preferred deployment platform for Django, many people use shared hosting, on which protocols such as FastCGI, SCGI or AJP are the only viable options." Again the implication is that these things are mutually exclusive and again they are not.

If you were to say "FastCGI and flup support via the runfcgi management command will be removed in Django 1.9. You may of course continue to use FastCGI and flup or some other FastCGI-to-WSGI deployment technology independently at your own risk, or you may of course switch to another WSGI deployment technology." then IMHO it would make more sense.

Yes I noticed the interest in forking flup in the thread. I'll check it out.

Thanks for responding!