Fixed #13820 -- Started the deprecation process for mod_python. Thanks to Robert Coup for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13648 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
23e85ef25f
commit
f611ffaab3
|
@ -1,5 +1,6 @@
|
||||||
import os
|
import os
|
||||||
from pprint import pformat
|
from pprint import pformat
|
||||||
|
from warnings import warn
|
||||||
|
|
||||||
from django import http
|
from django import http
|
||||||
from django.core import signals
|
from django.core import signals
|
||||||
|
@ -179,6 +180,9 @@ class ModPythonHandler(BaseHandler):
|
||||||
request_class = ModPythonRequest
|
request_class = ModPythonRequest
|
||||||
|
|
||||||
def __call__(self, req):
|
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
|
# mod_python fakes the environ, and thus doesn't process SetEnv. This fixes that
|
||||||
os.environ.update(req.subprocess_env)
|
os.environ.update(req.subprocess_env)
|
||||||
|
|
||||||
|
|
|
@ -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
|
:meth:`~django.contrib.admin.ModelAdmin.has_change_permission` can be used to
|
||||||
control the visibility and editability of objects in the admin.
|
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>`
|
See :ref:`serving the admin files <serving-the-admin-files>`
|
||||||
in the "How to use Django with mod_python" documentation.
|
in the "How to use Django with mod_wsgi" documentation.
|
||||||
|
|
||||||
My "list_filter" contains a ManyToManyField, but the filter doesn't display.
|
My "list_filter" contains a ManyToManyField, but the filter doesn't display.
|
||||||
----------------------------------------------------------------------------
|
----------------------------------------------------------------------------
|
||||||
|
|
|
@ -2,6 +2,13 @@
|
||||||
Authenticating against Django's user database from Apache
|
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
|
Since keeping multiple authentication databases in sync is a common problem when
|
||||||
dealing with Apache, you can configuring Apache to authenticate against Django's
|
dealing with Apache, you can configuring Apache to authenticate against Django's
|
||||||
:doc:`authentication system </topics/auth>` directly. For example, you
|
:doc:`authentication system </topics/auth>` directly. For example, you
|
||||||
|
|
|
@ -20,14 +20,14 @@ 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
|
(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.
|
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
|
Like mod_wsgi, FastCGI allows code to stay in memory, allowing requests to be
|
||||||
served with no startup time. Unlike mod_python_ (or `mod_perl`_), a FastCGI
|
served with no startup time. While mod_wsgi can either be configured embedded
|
||||||
process doesn't run inside the Web server process, but in a separate,
|
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.
|
persistent process.
|
||||||
|
|
||||||
.. _mod_wsgi: http://code.google.com/p/modwsgi/
|
.. _mod_wsgi: http://code.google.com/p/modwsgi/
|
||||||
.. _mod_perl: http://perl.apache.org/
|
.. _mod_perl: http://perl.apache.org/
|
||||||
.. _mod_python: http://www.modpython.org/
|
|
||||||
|
|
||||||
.. admonition:: Why run code in a separate process?
|
.. admonition:: Why run code in a separate process?
|
||||||
|
|
||||||
|
@ -35,8 +35,7 @@ persistent process.
|
||||||
languages (most notably PHP, Python and Perl) inside the process space of
|
languages (most notably PHP, Python and Perl) inside the process space of
|
||||||
your Web server. Although this lowers startup time -- because code doesn't
|
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
|
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
|
memory use.
|
||||||
Python interpreter, which uses up a considerable amount of RAM.
|
|
||||||
|
|
||||||
Due to the nature of FastCGI, it's even possible to have processes that run
|
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
|
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
|
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
|
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.
|
is also applicable in the setups detailed above.
|
||||||
|
|
||||||
Forcing the URL prefix to a particular value
|
Forcing the URL prefix to a particular value
|
||||||
|
|
|
@ -10,8 +10,8 @@ ways to easily deploy Django:
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
|
|
||||||
modwsgi
|
modwsgi
|
||||||
modpython
|
|
||||||
fastcgi
|
fastcgi
|
||||||
|
mod_python (deprecated) <modpython>
|
||||||
|
|
||||||
If you're new to deploying Django and/or Python, we'd recommend you try
|
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,
|
: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
|
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
|
.. highlight:: apache
|
||||||
|
|
||||||
The `mod_python`_ module for Apache_ can be used to deploy Django to a
|
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
|
.. _mod_python documentation: http://modpython.org/live/current/doc-html/directives.html
|
||||||
|
|
||||||
.. _serving-media-files:
|
|
||||||
|
|
||||||
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/
|
.. _Apache: http://httpd.apache.org/
|
||||||
.. _Cherokee: http://www.cherokee-project.com/
|
.. _Cherokee: http://www.cherokee-project.com/
|
||||||
|
|
||||||
.. _howto-deployment-modpython-serving-the-admin-files:
|
|
||||||
|
|
||||||
.. _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'
|
replace 'mysite.settings' with your correct settings file, and '/usr/local/django'
|
||||||
with your own project's location.
|
with your own project's location.
|
||||||
|
|
||||||
|
.. _serving-media-files:
|
||||||
|
|
||||||
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
|
.. _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
|
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.
|
production setting. Use this only for development.
|
||||||
|
|
||||||
For information on serving static files in an Apache production environment,
|
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
|
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``
|
* The ``no`` language code has been deprecated in favor of the ``nb``
|
||||||
language code.
|
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
|
* 2.0
|
||||||
* ``django.views.defaults.shortcut()``. This function has been moved
|
* ``django.views.defaults.shortcut()``. This function has been moved
|
||||||
to ``django.contrib.contenttypes.views.shortcut()`` as part of the
|
to ``django.contrib.contenttypes.views.shortcut()`` as part of the
|
||||||
|
|
|
@ -59,6 +59,12 @@ For more information, please consult Django's
|
||||||
``mod_python``
|
``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::
|
Example::
|
||||||
|
|
||||||
<VirtualHost *:80>
|
<VirtualHost *:80>
|
||||||
|
|
|
@ -393,8 +393,7 @@ Sent when Django begins processing an HTTP request.
|
||||||
Arguments sent with this signal:
|
Arguments sent with this signal:
|
||||||
|
|
||||||
``sender``
|
``sender``
|
||||||
The handler class -- i.e.
|
The handler class -- e.g.
|
||||||
:class:`django.core.handlers.modpython.ModPythonHandler` or
|
|
||||||
:class:`django.core.handlers.wsgi.WsgiHandler` -- that handled
|
:class:`django.core.handlers.wsgi.WsgiHandler` -- that handled
|
||||||
the request.
|
the request.
|
||||||
|
|
||||||
|
|
|
@ -42,13 +42,45 @@ custom widget to your form that sets the ``render_value`` argument::
|
||||||
username = forms.CharField(max_length=100)
|
username = forms.CharField(max_length=100)
|
||||||
password = forms.PasswordField(widget=forms.PasswordInput(render_value=True))
|
password = forms.PasswordField(widget=forms.PasswordInput(render_value=True))
|
||||||
|
|
||||||
|
.. _deprecated-features-1.3:
|
||||||
|
|
||||||
Features deprecated in 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
|
What's new in Django 1.3
|
||||||
========================
|
========================
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -27,27 +27,38 @@ probably already have it installed.
|
||||||
Install Apache and mod_wsgi
|
Install Apache and mod_wsgi
|
||||||
=============================
|
=============================
|
||||||
|
|
||||||
If you just want to experiment with Django, skip ahead to the next section;
|
If you just want to experiment with Django, skip ahead to the next
|
||||||
Django includes a lightweight web server you can use for testing, so you won't
|
section; Django includes a lightweight web server you can use for
|
||||||
need to set up Apache until you're ready to deploy Django in production.
|
testing, so you won't need to set up Apache until you're ready to
|
||||||
|
deploy Django in production.
|
||||||
|
|
||||||
If you want to use Django on a production site, use Apache with `mod_wsgi`_.
|
If you want to use Django on a production site, use Apache with
|
||||||
mod_wsgi is similar to mod_perl -- it embeds Python within Apache and loads
|
`mod_wsgi`_. mod_wsgi can operate in one of two modes: an embedded
|
||||||
Python code into memory when the server starts. Code stays in memory throughout
|
mode and a daemon mode. In embedded mode, mod_wsgi is similar to
|
||||||
the life of an Apache process, which leads to significant performance gains over
|
mod_perl -- it embeds Python within Apache and loads Python code into
|
||||||
other server arrangements. Make sure you have Apache installed, with the
|
memory when the server starts. Code stays in memory throughout the
|
||||||
mod_wsgi module activated. Django will work with any version of Apache that
|
life of an Apache process, which leads to significant performance
|
||||||
supports mod_wsgi.
|
gains over other server arrangements. In daemon mode, mod_wsgi spawns
|
||||||
|
an independent daemon process that handles requests. The daemon
|
||||||
|
process can run as a different user than the webserver, possibly
|
||||||
|
leading to improved security, and the daemon process can be restarted
|
||||||
|
without restarting the entire Apache webserver, possibly making
|
||||||
|
refreshing your codebase more seamless. Consult the mod_wsgi
|
||||||
|
documentation to determine which mode is right for your setup. Make
|
||||||
|
sure you have Apache installed, with the mod_wsgi module activated.
|
||||||
|
Django will work with any version of Apache that supports mod_wsgi.
|
||||||
|
|
||||||
See :doc:`How to use Django with mod_wsgi </howto/deployment/modwsgi>` for
|
See :doc:`How to use Django with mod_wsgi </howto/deployment/modwsgi>`
|
||||||
information on how to configure mod_wsgi once you have it installed.
|
for information on how to configure mod_wsgi once you have it
|
||||||
|
installed.
|
||||||
|
|
||||||
If you can't use mod_wsgi for some reason, fear not: Django supports many other
|
If you can't use mod_wsgi for some reason, fear not: Django supports
|
||||||
deployment options. A great second choice is :doc:`mod_python
|
many other deployment options. Another option is :doc:`FastCGI
|
||||||
</howto/deployment/modpython>`, the predecessor to mod_wsgi. Additionally, Django
|
</howto/deployment/fastcgi>`, perfect for using Django with servers
|
||||||
follows the WSGI_ spec, which allows it to run on a variety of server platforms.
|
other than Apache. Additionally, Django follows the WSGI_ spec, which
|
||||||
See the `server-arrangements wiki page`_ for specific installation instructions
|
allows it to run on a variety of server platforms. See the
|
||||||
for each platform.
|
`server-arrangements wiki page`_ for specific installation
|
||||||
|
instructions for each platform.
|
||||||
|
|
||||||
.. _Apache: http://httpd.apache.org/
|
.. _Apache: http://httpd.apache.org/
|
||||||
.. _mod_wsgi: http://code.google.com/p/modwsgi/
|
.. _mod_wsgi: http://code.google.com/p/modwsgi/
|
||||||
|
@ -255,15 +266,15 @@ latest bug fixes and improvements, follow these instructions:
|
||||||
links. (Environment variables can be defined on Windows systems `from the
|
links. (Environment variables can be defined on Windows systems `from the
|
||||||
Control Panel`_.)
|
Control Panel`_.)
|
||||||
|
|
||||||
.. admonition:: What about Apache and mod_python?
|
.. admonition:: What about Apache and mod_wsgi?
|
||||||
|
|
||||||
If you take the approach of setting ``PYTHONPATH``, you'll need to
|
If you take the approach of setting ``PYTHONPATH``, you'll need
|
||||||
remember to do the same thing in your Apache configuration once you
|
to remember to do the same thing in your WSGI application once
|
||||||
deploy your production site. Do this by setting ``PythonPath`` in your
|
you deploy your production site. Do this by appending to
|
||||||
Apache configuration file.
|
``sys.path`` in your WSGI application.
|
||||||
|
|
||||||
More information about deployment is available, of course, in our
|
More information about deployment is available, of course, in our
|
||||||
:doc:`How to use Django with mod_python </howto/deployment/modpython>`
|
:doc:`How to use Django with mod_wsgi </howto/deployment/modwsgi>`
|
||||||
documentation.
|
documentation.
|
||||||
|
|
||||||
4. On Unix-like systems, create a symbolic link to the file
|
4. On Unix-like systems, create a symbolic link to the file
|
||||||
|
|
|
@ -64,20 +64,19 @@ Use the ``--settings`` command-line argument to specify the settings manually::
|
||||||
|
|
||||||
.. _django-admin.py: ../django-admin/
|
.. _django-admin.py: ../django-admin/
|
||||||
|
|
||||||
On the server (mod_python)
|
On the server (mod_wsgi)
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
||||||
In your live server environment, you'll need to tell Apache/mod_python which
|
In your live server environment, you'll need to tell your WSGI
|
||||||
settings file to use. Do that with ``SetEnv``::
|
application what settings file to use. Do that with ``os.environ``::
|
||||||
|
|
||||||
<Location "/mysite/">
|
import os
|
||||||
SetHandler python-program
|
|
||||||
PythonHandler django.core.handlers.modpython
|
|
||||||
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
|
|
||||||
</Location>
|
|
||||||
|
|
||||||
Read the :doc:`Django mod_python documentation </howto/deployment/modpython>` for
|
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
|
||||||
more information.
|
|
||||||
|
Read the :doc:`Django mod_wsgi documentation
|
||||||
|
</howto/deployment/modwsgi>` for more information and other common
|
||||||
|
elements to a Django WSGI application.
|
||||||
|
|
||||||
Default settings
|
Default settings
|
||||||
================
|
================
|
||||||
|
|
Loading…
Reference in New Issue