Permalink
Browse files

Fixed #13820 -- Started the deprecation process for mod_python. Thank…

…s to Robert Coup for the patch.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@13648 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
freakboy3742 committed Aug 28, 2010
1 parent 23e85ef commit f611ffaab3be0c9a9d21b6bd404fdefb30a3e909
@@ -1,5 +1,6 @@
import os
from pprint import pformat
from warnings import warn
from django import http
from django.core import signals
@@ -179,6 +180,9 @@ class ModPythonHandler(BaseHandler):
request_class = ModPythonRequest
def __call__(self, req):
warn(('The mod_python handler is deprecated; use a WSGI or FastCGI server instead.'),
PendingDeprecationWarning)
# mod_python fakes the environ, and thus doesn't process SetEnv. This fixes that
os.environ.update(req.subprocess_env)
View
@@ -52,11 +52,11 @@ admin. Using the same trick of extracting the user from the request, the
:meth:`~django.contrib.admin.ModelAdmin.has_change_permission` can be used to
control the visibility and editability of objects in the admin.
My admin-site CSS and images showed up fine using the development server, but they're not displaying when using mod_python.
My admin-site CSS and images showed up fine using the development server, but they're not displaying when using mod_wsgi.
---------------------------------------------------------------------------------------------------------------------------
See :ref:`serving the admin files <howto-deployment-modpython-serving-the-admin-files>`
in the "How to use Django with mod_python" documentation.
See :ref:`serving the admin files <serving-the-admin-files>`
in the "How to use Django with mod_wsgi" documentation.
My "list_filter" contains a ManyToManyField, but the filter doesn't display.
----------------------------------------------------------------------------
@@ -2,6 +2,13 @@
Authenticating against Django's user database from Apache
=========================================================
.. warning::
Support for mod_python has been deprecated within Django. At that
time, this method of authentication will no longer be provided by
Django. The community is welcome to offer its own alternate
solutions using WSGI middleware or other approaches.
Since keeping multiple authentication databases in sync is a common problem when
dealing with Apache, you can configuring Apache to authenticate against Django's
:doc:`authentication system </topics/auth>` directly. For example, you
@@ -20,23 +20,22 @@ serve pages to a Web server. The Web server delegates the incoming Web requests
(via a socket) to FastCGI, which executes the code and passes the response back
to the Web server, which, in turn, passes it back to the client's Web browser.
Like mod_python, FastCGI allows code to stay in memory, allowing requests to be
served with no startup time. Unlike mod_python_ (or `mod_perl`_), a FastCGI
process doesn't run inside the Web server process, but in a separate,
Like mod_wsgi, FastCGI allows code to stay in memory, allowing requests to be
served with no startup time. While mod_wsgi can either be configured embedded
in the Apache webserver process or as a separate daemon process, a FastCGI
process never runs inside the Web server process, always in a separate,
persistent process.
.. _mod_wsgi: http://code.google.com/p/modwsgi/
.. _mod_perl: http://perl.apache.org/
.. _mod_python: http://www.modpython.org/
.. admonition:: Why run code in a separate process?
The traditional ``mod_*`` arrangements in Apache embed various scripting
languages (most notably PHP, Python and Perl) inside the process space of
your Web server. Although this lowers startup time -- because code doesn't
have to be read off disk for every request -- it comes at the cost of
memory use. For mod_python, for example, every Apache process gets its own
Python interpreter, which uses up a considerable amount of RAM.
memory use.
Due to the nature of FastCGI, it's even possible to have processes that run
under a different user account than the Web server process. That's a nice
@@ -361,7 +360,7 @@ Serving admin media files
Regardless of the server and configuration you eventually decide to use, you
will also need to give some thought to how to serve the admin media files. The
advice given in the :ref:`modpython <serving-the-admin-files>` documentation
advice given in the :ref:`mod_wsgi <serving-the-admin-files>` documentation
is also applicable in the setups detailed above.
Forcing the URL prefix to a particular value
@@ -10,8 +10,8 @@ ways to easily deploy Django:
:maxdepth: 1
modwsgi
modpython
fastcgi
mod_python (deprecated) <modpython>
If you're new to deploying Django and/or Python, we'd recommend you try
:doc:`mod_wsgi </howto/deployment/modwsgi>` first. In most cases it'll be the easiest,
@@ -2,6 +2,13 @@
How to use Django with Apache and mod_python
============================================
.. warning::
Support for mod_python will be deprecated in a future release of Django. If
you are configuring a new deployment, you are strongly encouraged to
consider using :doc:`mod_wsgi </howto/deployment/modwsgi>` or any of the
other :doc:`supported backends </howto/deployment/index>`.
.. highlight:: apache
The `mod_python`_ module for Apache_ can be used to deploy Django to a
@@ -214,8 +221,6 @@ Or add the debugging information to the template of your page.
.. _mod_python documentation: http://modpython.org/live/current/doc-html/directives.html
.. _serving-media-files:
Serving media files
===================
@@ -267,10 +272,6 @@ the ``media`` subdirectory and any URL that ends with ``.jpg``, ``.gif`` or
.. _Apache: http://httpd.apache.org/
.. _Cherokee: http://www.cherokee-project.com/
.. _howto-deployment-modpython-serving-the-admin-files:
.. _serving-the-admin-files:
Serving the admin files
=======================
@@ -53,6 +53,8 @@ just above the final ``import`` line to place your project on the path. Remember
replace 'mysite.settings' with your correct settings file, and '/usr/local/django'
with your own project's location.
.. _serving-media-files:
Serving media files
===================
@@ -106,6 +108,29 @@ in the mod_wsgi documentation on `hosting static files`_.
.. _hosting static files: http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#Hosting_Of_Static_Files
.. _serving-the-admin-files:
Serving the admin files
=======================
Note that the Django development server automagically serves admin media files,
but this is not the case when you use any other server arrangement. You're
responsible for setting up Apache, or whichever media server you're using, to
serve the admin files.
The admin files live in (:file:`django/contrib/admin/media`) of the Django
distribution.
Here are two recommended approaches:
1. Create a symbolic link to the admin media files from within your
document root. This way, all of your Django-related files -- code **and**
templates -- stay in one place, and you'll still be able to ``svn
update`` your code to get the latest admin templates, if they change.
2. Or, copy the admin media files so that they live within your Apache
document root.
Details
=======
@@ -31,7 +31,7 @@ Using this method is **inefficient** and **insecure**. Do not use this in a
production setting. Use this only for development.
For information on serving static files in an Apache production environment,
see the :ref:`Django mod_python documentation <serving-media-files>`.
see the :ref:`Django mod_wsgi documentation <serving-media-files>`.
How to do it
============
@@ -98,6 +98,10 @@ their deprecation, as per the :ref:`Django deprecation policy
* The ``no`` language code has been deprecated in favor of the ``nb``
language code.
* 1.5
* The ``mod_python`` request handler has been deprecated since the 1.3
release. The ``mod_wsgi`` handler should be used instead.
* 2.0
* ``django.views.defaults.shortcut()``. This function has been moved
to ``django.contrib.contenttypes.views.shortcut()`` as part of the
@@ -6,15 +6,15 @@ Deploying GeoDjango
GeoDjango uses the GDAL geospatial library which is
not thread safe at this time. Thus, it is *highly* recommended
to not use threading when deploying -- in other words, use a
to not use threading when deploying -- in other words, use a
an appropriate configuration of Apache or the prefork method
when using FastCGI through another web server.
Apache
======
In this section there are some example ``VirtualHost`` directives for
In this section there are some example ``VirtualHost`` directives for
when deploying using either ``mod_python`` or ``mod_wsgi``. At this
time, we recommend ``mod_wsgi``, as it is now officially recommended
time, we recommend ``mod_wsgi``, as it is now officially recommended
way to deploy Django applications with Apache. Moreover, if
``mod_python`` is used, then a prefork version of Apache must also be
used. As long as ``mod_wsgi`` is configured correctly, it does not
@@ -23,7 +23,7 @@ matter whether the version of Apache is prefork or worker.
.. note::
The ``Alias`` and ``Directory`` configurations in the the examples
below use an example path to a system-wide installation folder of Django.
below use an example path to a system-wide installation folder of Django.
Substitute in an appropriate location, if necessary, as it may be
different than the path on your system.
@@ -36,21 +36,21 @@ Example::
WSGIDaemonProcess geodjango user=geo group=geo processes=5 threads=1
WSGIProcessGroup geodjango
WSGIScriptAlias / /home/geo/geodjango/world.wsgi
Alias /media/ "/usr/lib/python2.5/site-packages/django/contrib/admin/media/"
<Directory "/usr/lib/python2.5/site-packages/django/contrib/admin/media/">
Order allow,deny
Options Indexes
Allow from all
IndexOptions FancyIndexing
</Directory>
</VirtualHost>
.. warning::
If the ``WSGIDaemonProcess`` attribute ``threads`` is not set to ``1``, then
Apache may crash when running your GeoDjango application. Increase the
Apache may crash when running your GeoDjango application. Increase the
number of ``processes`` instead.
For more information, please consult Django's
@@ -59,23 +59,29 @@ For more information, please consult Django's
``mod_python``
--------------
.. warning::
Support for mod_python will be deprecated in a future release of Django. If
you are configuring a new deployment, you are strongly encouraged to
consider using :doc:`mod_wsgi </howto/deployment/modwsgi>` or any of the
other :doc:`supported backends </howto/deployment/index>`.
Example::
<VirtualHost *:80>
<Location "/">
SetHandler mod_python
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE world.settings
PythonDebug On
PythonPath "['/var/www/apps'] + sys.path"
</Location>
Alias /media/ "/usr/lib/python2.5/site-packages/django/contrib/admin/media/"
<Location "/media">
SetHandler None
</Location>
</VirtualHost>
.. warning::
View
@@ -393,8 +393,7 @@ Sent when Django begins processing an HTTP request.
Arguments sent with this signal:
``sender``
The handler class -- i.e.
:class:`django.core.handlers.modpython.ModPythonHandler` or
The handler class -- e.g.
:class:`django.core.handlers.wsgi.WsgiHandler` -- that handled
the request.
View
@@ -42,13 +42,45 @@ custom widget to your form that sets the ``render_value`` argument::
username = forms.CharField(max_length=100)
password = forms.PasswordField(widget=forms.PasswordInput(render_value=True))
.. _deprecated-features-1.3:
Features deprecated in 1.3
==========================
Django 1.3 deprecates some features from earlier releases.
These features are still supported, but will be gradually phased out
over the next few release cycles.
Code taking advantage of any of the features below will raise a
``PendingDeprecationWarning`` in Django 1.3. This warning will be
silent by default, but may be turned on using Python's `warnings
module`_, or by running Python with a ``-Wd`` or `-Wall` flag.
.. _warnings module: http://docs.python.org/library/warnings.html
In Django 1.4, these warnings will become a ``DeprecationWarning``,
which is *not* silent. In Django 1.5 support for these features will
be removed entirely.
.. seealso::
For more details, see the documentation :doc:`Django's release process
</internals/release-process>` and our :doc:`deprecation timeline
</internals/deprecation>`.`
``mod_python`` support
~~~~~~~~~~~~~~~~~~~~~~
The ``mod_python`` library has not had a release since 2007 or a commit since
2008. The Apache Foundation board voted to remove ``mod_python`` from the set
of active projects in its version control repositories, and its lead developer
has shifted all of his efforts toward the lighter, slimmer, more stable, and
more flexible ``mod_wsgi`` backend.
If you are currently using the ``mod_python`` request handler, it is strongly
encouraged you redeploy your Django instances using :doc:`mod_wsgi
</howto/deployment/modwsgi>`.
What's new in Django 1.3
========================
Oops, something went wrong.

0 comments on commit f611ffa

Please sign in to comment.