1.3: Start deprecating mod_python?
Robert Coup
While people are throwing around 1.3 ideas... I think we should start
the process of deprecating and removing support for mod_python. Why?
* mod_wsgi is better in every way.
* mod_python hasn't had a release since 2007, or a commit since 2008;
it's a dead end. The Apache Foundation board voted this month to
retire it to the "Attic" - effectively beginning to wind it up.
http://attic.apache.org/projects/quetzalcoatl.html
* if people are still using it in production in 2012, it is easy to
maintain an external handler.
I'm proposing the following very predictable timeline:
Django 1.3
Use of the modpython handler raises a PendingDeprecationWarning.
Update the docs to discourage people from using it.
Django 1.4
Use of the modpython handler raises a DeprecationWarning.
Django 1.5
Remove the modpython handler from Django (and put it on bitbucket/github?)
If someone magically steps up and brings it back to life, we can
always halt/reverse the process.
Objections?
Rob :)
Jacob Kaplan-Moss
> The other huge win -- besides your great versions -- is that without
... er, *reasons*.
Damned wires getting crossed in my brain.
Jacob
Jacob Kaplan-Moss
<rober...@koordinates.com> wrote:
> While people are throwing around 1.3 ideas... I think we should start
> the process of deprecating and removing support for mod_python. Why?
The other huge win -- besides your great versions -- is that without
mod_python support Django just becomes a pure WSGI framework, meaning
there's just a single codepath and a single way to deploy Django.
Much, much easier.
> Objections?
None whatsoever. I'm +1e100 or so.
Jacob
Gustavo Narea
http://groups.google.com/group/django-developers/browse_thread/thread/2e20f4ae486800a1
Anyway, I'm +1 on this.
On Jun 22, 10:47 pm, Robert Coup <robert.c...@koordinates.com> wrote:
> Hey folks,
>
> While people are throwing around 1.3 ideas... I think we should start
> the process of deprecating and removing support for mod_python. Why?
>
> * mod_wsgi is better in every way.
> * mod_python hasn't had a release since 2007, or a commit since 2008;
> it's a dead end. The Apache Foundation board voted this month to
Alex Gaynor
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
Another +1 (not that this needs it). However, I wonder if there is a
case to be made to be even more aggressive in the deprecation process
(DeprecationWarning now, instead of Pending) seeing as how it's
already dead in the water upstream?
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
Jerome Leclanche
it's dead, I don't see any reason to support it for three full release
cycles.
Russell Keith-Magee
None from me. +1.
The only catch I can think of that hasn't been raised is the hotshot
profiling handler; it's currently dependent on the modpython handler.
I don't think there's a whole lot of extra work required to port it
over, but it's worth putting on the todo list so it isn't forgotten.
Yours,
Russ Magee %-)
> Jacob
Russell Keith-Magee
It may be dead in the water upstream, but that doesn't change the fact
that our downstream may be dependent on the code. Keeping the code
around doesn't seriously affect us, but it could be an inconvenience
to our user base, so I'm not inclined to accelerate the process.
Yours,
Russ Magee %-)
Robert Coup
> Agreed. mod_python was already "not recommended" for very long; now
> it's dead, I don't see any reason to support it for three full release
> cycles.
I don't either, but I figured the deprecation policy[1] applies to
deployment-related code as much as any other code...
[1] http://docs.djangoproject.com/en/1.2/internals/release-process/#internal-release-deprecation-policy
Using the 'postgresql' backend is vastly more insane than using
mod_python, but it still doesn't die until 1.4...
Sooner we start, sooner we finish!
Rob :)
Graham Dumpleton
On Jun 23, 9:41 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> > On Tue, Jun 22, 2010 at 4:47 PM, Robert Coup
> > <robert.c...@koordinates.com> wrote:
> >> While people are throwing around 1.3 ideas... I think we should start
> >> the process of deprecating and removing support for mod_python. Why?
>
> > The other huge win -- besides your great versions -- is that without
> > mod_python support Django just becomes a pure WSGI framework, meaning
> > there's just a single codepath and a single way to deploy Django.
> > Much, much easier.
>
> >> Objections?
>
> > None whatsoever. I'm +1e100 or so.
>
> None from me. +1.
>
> The only catch I can think of that hasn't been raised is the hotshot
> profiling handler; it's currently dependent on the modpython handler.
> I don't think there's a whole lot of extra work required to port it
> over, but it's worth putting on the todo list so it isn't forgotten.
I can have a quick look?
Graham
Alex Gaynor
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
http://code.djangoproject.com/browser/django/trunk/django/core/handlers/profiler-hotshot.py
(Honestly does anyone use this?)
Jeremy Dunck
...
> http://code.djangoproject.com/browser/django/trunk/django/core/handlers/profiler-hotshot.py
>
> (Honestly does anyone use this?)
I think I did a few times in the dark days before debug-toolbar, etc.
Graham Dumpleton
> (Honestly does anyone use this?)
This sort of thing is easily done with a WSGI middleware like wrapper
these days. As such, it is better left to third party packages to
provide such tools.
# Original WSGI application.
import os, sys
sys.path.append('/usr/local/django')
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
# Logging WSGI middleware.
import threading
import hotshot
import time
import os
class ProfilingMiddleware:
def __init__(self, application, savedir):
self.__application = application
self.__savedir = savedir
self.__lock = threading.Lock()
self.__pid = os.getpid()
self.__count = 0
def __call__(self, environ, start_response):
self.__lock.acquire()
self.__count += 1
count = self.__count
self.__lock.release()
key = "%s-%s-%s" % (time.time(), self.__pid, count)
savedir = os.path.join(self.__savedir, key + ".prof")
profiler = hotshot.Profile(savedir)
return profiler.runcall(self.__application, environ,
start_response)
application = ProfilingMiddleware(application, '/tmp/wsgi')
Sergej dergatsjev eecho
2010/6/22 Robert Coup <rober...@koordinates.com>:
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
--
Sergej Dergatsjev
E-mail: sergej.d...@gmail.com
Skype: SergejDergatsjev
Site: http://www.eecho.info
Anton Bessonov
> Hey folks,
>
> While people are throwing around 1.3 ideas... I think we should start
> the process of deprecating and removing support for mod_python. Why?
>
> * mod_wsgi is better in every way.
>
Engine. Drop DJango Template Engine and support Jinja2?
> * mod_python hasn't had a release since 2007, or a commit since 2008;
> it's a dead end. The Apache Foundation board voted this month to
> retire it to the "Attic" - effectively beginning to wind it up.
> http://attic.apache.org/projects/quetzalcoatl.html
>
> * if people are still using it in production in 2012, it is easy to
> maintain an external handler.
>
>
enterprise are still using it in production in 2199.
> I'm proposing the following very predictable timeline:
>
> Django 1.3
> Use of the modpython handler raises a PendingDeprecationWarning.
> Update the docs to discourage people from using it.
> Django 1.4
> Use of the modpython handler raises a DeprecationWarning.
> Django 1.5
> Remove the modpython handler from Django (and put it on bitbucket/github?)
>
> If someone magically steps up and brings it back to life, we can
> always halt/reverse the process.
>
> Objections?
>
> Rob :)
>
>
-1. This is'nt arguments to remove support for mod_python. It's produce
sensless work.
Russell Keith-Magee
>
>> Hey folks,
>>
>> While people are throwing around 1.3 ideas... I think we should start
>> the process of deprecating and removing support for mod_python. Why?
>>
>> * mod_wsgi is better in every way.
>>
>
> And? Jinja2-Template Engine is every way better as Django Template Engine.
> Drop DJango Template Engine and support Jinja2?
That's a matter of opinion, and it isn't an opinion I or the rest of
the core team share.
The comparison with mod_wsgi isn't a good one, either. mod_python is
an interface that is supported by Apache. mod_wsgi, on the other hand,
is Apache's implementation of the WSGI standard. Even if mod_python
weren't deprecated, there is a clear technical reason for preferring
mod_wsgi.
>> * mod_python hasn't had a release since 2007, or a commit since 2008;
>> it's a dead end. The Apache Foundation board voted this month to
>> retire it to the "Attic" - effectively beginning to wind it up.
>> http://attic.apache.org/projects/quetzalcoatl.html
>>
>
> And? Cobol is old and dead, but see financial and insurance sector.
Cobol is old, but it isn't dead. There are still vendors that sell and
support Cobol.
Apache is the only vendor of mod_python; they haven't updated it since
2008, and they've clearly indicated that they have no intention of
doing so in the future.
> -1. This is'nt arguments to remove support for mod_python. It's produce
> sensless work.
No - senseless work would be maintaining support for an handler
interface that isn't supported by the vendor that provided it.
Yours,
Russ Magee %-)
Robert Coup
On Wed, Jun 23, 2010 at 10:13 PM, Anton Bessonov <exe...@googlemail.com> wrote:
>>
>> * mod_wsgi is better in every way.
>
> And? Jinja2-Template Engine is every way better as Django Template Engine.
> Drop DJango Template Engine and support Jinja2?
Russell explained it, but mod_wsgi:
- is actively developed
- implements the python web-app standards
- has great documentation
- supports both Python 2 & 3
- is trying hard to address different hosting models, including shared hosting.
mod_python on the other hand:
- is abandoned & has no developers
- has a LOT of outstanding bugs, many quite serious
- will never work with Python 3 without enormous effort
- does everything its own special way
>>
>> * mod_python hasn't had a release since 2007, or a commit since 2008;
>> it's a dead end. The Apache Foundation board voted this month to
>> retire it to the "Attic" - effectively beginning to wind it up.
>> http://attic.apache.org/projects/quetzalcoatl.html
>>
>
> And? Cobol is old and dead, but see financial and insurance sector.
People are actively developing in and with COBOL (eg. the industries
you mentioned). The cool kids don't like it - that's different. A new
Visual Studio COBOL tool was released just a couple of months ago, as
an example.
>>
>> * if people are still using it in production in 2012, it is easy to
>> maintain an external handler.
>
> External handler is good idea generally for all handlers. And yes,
> enterprise are still using it in production in 2199.
They'd have to be both:
- upgrading Django
- upgrading Python (since by Django1.5 you'll need Python2.7 iirc)
- not upgrading apache (I'd expect mod_python will break with new
apache releases at some point)
- not upgrading mod_python
> -1. This is'nt arguments to remove support for mod_python. It's produce
> sensless work.
As Gustavo said in the other thread, removing mod_python will simplify
request handling quite a bit, allow Django to be a pure WSGI
application (so it can interact better with other Python WSGI apps),
and it's less code to maintain - we don't want unused code rotting in
the Django codebase.
Rob :)
Robert Coup
> Jacob said: I'm +1e100 or so.
> Russ said: +1.
Now lives as http://code.djangoproject.com/ticket/13820
>
> The only catch I can think of that hasn't been raised is the hotshot
> profiling handler; it's currently dependent on the modpython handler.
> I don't think there's a whole lot of extra work required to port it
> over, but it's worth putting on the todo list so it isn't forgotten.
Do we:
1. build a WSGI-based equivalent handler?
2. deprecate it with mod_python, post Graham's code on
django-snippets/wiki, then point people there (or to
django-debug-toolbar) in the release/deprecation notes?
I'd vote for #2, it's trivial code but is (afaik) unused - and there
are better places for that code to live.
Rob :)
Graham Dumpleton
On Jun 24, 6:55 am, Robert Coup <robert.c...@koordinates.com> wrote:
> Hi again,
>
> > Jacob said: I'm +1e100 or so.
> > Russ said: +1.
>
>
>
> > The only catch I can think of that hasn't been raised is the hotshot
> > profiling handler; it's currently dependent on the modpython handler.
> > I don't think there's a whole lot of extra work required to port it
> > over, but it's worth putting on the todo list so it isn't forgotten.
>
> Do we:
> 1. build a WSGI-based equivalent handler?
> 2. deprecate it with mod_python, post Graham's code on
> django-snippets/wiki, then point people there (or to
> django-debug-toolbar) in the release/deprecation notes?
>
> I'd vote for #2, it's trivial code but is (afaik) unused - and there
> are better places for that code to live.
pros and cons of each, I am likely to include a section on using
profiling tools in:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
So people could always go there.
Graham
Russell Keith-Magee
Call me +1 for #2. In all honesty, I've never used the profiler
backend -- I just mentioned it because I knew it existed, and I didn't
want dead code to linger through lack of attention. The fact that
mod_wsgi has been the recommended interface for as long as it has yet
nobody has complained about the absence of a profiler would seem to
suggest that it has limited usage.
Given that there are better tools out there, I'm inclined to
deprecated in favor of making this someone elses bailiwick.
Yours,
Russ Magee %-)
Joshua 'jag' Ginsberg
documentation references that are mod_python centric. Also, the
authentication handler that mod_python provides will be deprecated
when the handler goes away.
-jag
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
--
Joshua "jag" Ginsberg <j...@flowtheory.net>
http://www.flowtheory.net/
Kevin Howerton
that WSGI debug page, rather than relying on the apache logging
mechanisms.
In django land ... there's django-devserver, django-debugtoolbar, and
django-lumberjack.
All of them more or less share the same profilers and such. The only
differences being that devserver targets the terminal, debugtoolbar
targets the in browser toolbar, and lumberjack tries to be a bit more
flexible and uses python-logging.
-k
>
> Once I have reviewed what other profiler options may exist and the
> pros and cons of each, I am likely to include a section on using
> profiling tools in:
>
> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
>
> So people could always go there.
>
> Graham
>