Commits

Anonymous committed 631b07c

Reintegration de modpython.txt dans la doc auformat sphinx - suppression de l'ancien modpython.txt

Comments (0)

Files changed (3)

docs/howto/deployment/index.txt

+.. _howto-deployment-index:
+
+Déployer Django
+===============
+
+La quantité astronomique de raccourcis dans Django pour faciliter la vie des
+développeurs n'auraient aucune utilisé, si vous ne pouvez pas déployer
+simplement vos sites. Depuis le début de sa conception, la facilité de 
+déploiement est un objectif majeur. Il y a plusieurs façons de déployer 
+simplement une application Django :
+
+.. toctree::
+   :maxdepth: 1
+   
+   modpython
+   fastcgi
+   
+:ref:`Deployer avec Apache et mod_python <howto-deployment-modpython>` est la 
+méthode recommandée. Commencez par celle-ci si vous êtes pas sur de votre 
+chemin.
+
+.. seealso::
+
+    * `Chapitre 20 de The Django Book`_ traite du déploiement et plus 
+      spéciquelement de la montée en charge de façon plus détaillée.
+      
+    * `mod_wsgi`_ est un nouveau venu dans le monde du déploiement avec Python
+      mais il séduit rapidement les masses. Actuellement, il y a quelques
+      obstacles à sauter pour `utiliser mod_wsgi avec Django`_ mais mod_wsgi
+      est plutôt bien noté par ses utilisateurs.`
+
+.. _Chapitre 20 de The Django Book: http://djangobook.com/en/1.0/chapter20/
+.. _mod_wsgi: http://code.google.com/p/modwsgi/
+.. _utiliser mod_wsgi avec Django: http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

docs/howto/deployment/modpython.txt

+Multiple Django installations on the same Apache
+================================================
+
+It's entirely possible to run multiple Django installations on the same Apache
+instance. Just use ``VirtualHost`` for that, like so::
+
+    NameVirtualHost *
+
+    <VirtualHost *>
+        ServerName www.example.com
+        # ...
+        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
+    </VirtualHost>
+
+    <VirtualHost *>
+        ServerName www2.example.com
+        # ...
+        SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
+    </VirtualHost>
+
+If you need to put two Django installations within the same ``VirtualHost``
+(or in different ``VirtualHost`` blocks that share the same server name),
+you'll need to take a special precaution to ensure mod_python's cache doesn't
+mess things up. Use the ``PythonInterpreter`` directive to give different
+``<Location>`` directives separate interpreters::
+
+    <VirtualHost *>
+        ServerName www.example.com
+        # ...
+        <Location "/something">
+            SetEnv DJANGO_SETTINGS_MODULE mysite.settings
+            PythonInterpreter mysite
+        </Location>
+
+        <Location "/otherthing">
+            SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
+            PythonInterpreter othersite
+        </Location>
+    </VirtualHost>
+
+The values of ``PythonInterpreter`` don't really matter, as long as they're
+different between the two ``Location`` blocks.
+
+Running a development server with mod_python
+============================================
+
+If you use mod_python for your development server, you can avoid the hassle of
+having to restart the server each time you make code changes. Just set
+``MaxRequestsPerChild 1`` in your ``httpd.conf`` file to force Apache to reload
+everything for each request. But don't do that on a production server, or we'll
+revoke your Django privileges.
+
+If you're the type of programmer who debugs using scattered ``print``
+statements, note that ``print`` statements have no effect in mod_python; they
+don't appear in the Apache log, as one might expect. If you have the need to
+print debugging information in a mod_python setup, either do this::
+
+    assert False, the_value_i_want_to_see
+
+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
+===================
+
+Django doesn't serve media files itself; it leaves that job to whichever Web
+server you choose.
+
+We recommend using a separate Web server -- i.e., one that's not also running
+Django -- for serving media. Here are some good choices:
+
+    * lighttpd_
+    * TUX_
+    * A stripped-down version of Apache_
+
+If, however, you have no option but to serve media files on the same Apache
+``VirtualHost`` as Django, here's how you can turn off mod_python for a
+particular part of the site::
+
+    <Location "/media">
+        SetHandler None
+    </Location>
+
+Just change ``Location`` to the root URL of your media files. You can also use
+``<LocationMatch>`` to match a regular expression.
+
+This example sets up Django at the site root but explicitly disables Django for
+the ``media`` subdirectory and any URL that ends with ``.jpg``, ``.gif`` or
+``.png``::
+
+    <Location "/">
+        SetHandler python-program
+        PythonHandler django.core.handlers.modpython
+        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
+    </Location>
+
+    <Location "/media">
+        SetHandler None
+    </Location>
+
+    <LocationMatch "\.(jpg|gif|png)$">
+        SetHandler None
+    </LocationMatch>
+
+
+.. _lighttpd: http://www.lighttpd.net/
+.. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
+.. _Apache: http://httpd.apache.org/
+
+.. _howto-deployment-modpython-serving-the-admin-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.
+
+Using "eggs" with mod_python
+============================
+
+If you installed Django from a Python egg_ or are using eggs in your Django
+project, some extra configuration is required. Create an extra file in your
+project (or somewhere else) that contains something like the following:
+
+.. code-block:: python
+
+    import os
+    os.environ['PYTHON_EGG_CACHE'] = '/some/directory'
+
+Here, ``/some/directory`` is a directory that the Apache webserver process can
+write to. It will be used as the location for any unpacking of code the eggs
+need to do.
+
+Then you have to tell mod_python to import this file before doing anything
+else. This is done using the PythonImport_ directive to mod_python. You need
+to ensure that you have specified the ``PythonInterpreter`` directive to
+mod_python as described above__ (you need to do this even if you aren't
+serving multiple installations in this case). Then add the ``PythonImport``
+line in the main server configuration (i.e., outside the ``Location`` or
+``VirtualHost`` sections). For example::
+
+    PythonInterpreter my_django
+    PythonImport /path/to/my/project/file.py my_django
+
+Note that you can use an absolute path here (or a normal dotted import path),
+as described in the `mod_python manual`_. We use an absolute path in the
+above example because if any Python path modifications are required to access
+your project, they will not have been done at the time the ``PythonImport``
+line is processed.
+
+.. _Egg: http://peak.telecommunity.com/DevCenter/PythonEggs
+.. _PythonImport: http://www.modpython.org/live/current/doc-html/dir-other-pimp.html
+.. _mod_python manual: PythonImport_
+__ `Multiple Django installations on the same Apache`_
+
+Error handling
+==============
+
+When you use Apache/mod_python, errors will be caught by Django -- in other
+words, they won't propagate to the Apache level and won't appear in the Apache
+``error_log``.
+
+The exception for this is if something is really wonky in your Django setup. In
+that case, you'll see an "Internal Server Error" page in your browser and the
+full Python traceback in your Apache ``error_log`` file. The ``error_log``
+traceback is spread over multiple lines. (Yes, this is ugly and rather hard to
+read, but it's how mod_python does things.)
+
+If you get a segmentation fault
+===============================
+
+If Apache causes a segmentation fault, there are two probable causes, neither
+of which has to do with Django itself.
+
+    1. It may be because your Python code is importing the "pyexpat" module,
+       which may conflict with the version embedded in Apache. For full
+       information, see `Expat Causing Apache Crash`_.
+       
+    2. It may be because you're running mod_python and mod_php in the same
+       Apache instance, with MySQL as your database backend. In some cases,
+       this causes a known mod_python issue due to version conflicts in PHP and
+       the Python MySQL backend. There's full information in the
+       `mod_python FAQ entry`_.
+
+If you continue to have problems setting up mod_python, a good thing to do is
+get a barebones mod_python site working, without the Django framework. This is
+an easy way to isolate mod_python-specific problems. `Getting mod_python Working`_
+details this procedure.
+
+The next step should be to edit your test code and add an import of any
+Django-specific code you're using -- your views, your models, your URLconf,
+your RSS configuration, etc. Put these imports in your test handler function
+and access your test URL in a browser. If this causes a crash, you've confirmed
+it's the importing of Django code that causes the problem. Gradually reduce the
+set of imports until it stops crashing, so as to find the specific module that
+causes the problem. Drop down further into modules and look into their imports,
+as necessary.
+
+.. _Expat Causing Apache Crash: http://www.dscpl.com.au/articles/modpython-006.html
+.. _mod_python FAQ entry: http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp
+.. _Getting mod_python Working: http://www.dscpl.com.au/articles/modpython-001.html
+
+

olddocs/modpython.txt

-=======================================
-Comment utiliser Django avec mod_python
-=======================================
-
-Apache_ avec `mod_python`_ est actuellement la configuration recommandée pour 
-un serveur de production.
-
-mod_python est similaire à `mod_perl`_ : Il embarque Python au sein d'Apache 
-et charge Python en mémoire lorsque le serveur démarre. Python reste en mémoire 
-tout le temps sans être lié aux process Apache, ce qui conduit à un gain de 
-performance sensible.
-
-Django requiert Apache 2.x et mod_python 3.x, et vous devriez utiliser Apache 
-en mode `prefork MPM`_, et non pas en mode `worker MPM`_.
-
-Vous pouvez aussi être intéressé par `Comment utilisez Django avec FastCGI, 
-SCGI ou AJP`_ (qui couvre aussi SCGI et AJP).
-
-.. _Apache: http://httpd.apache.org/
-.. _mod_python: http://www.modpython.org/
-.. _mod_perl: http://perl.apache.org/
-.. _prefork MPM: http://httpd.apache.org/docs/2.2/mod/prefork.html
-.. _worker MPM: http://httpd.apache.org/docs/2.2/mod/worker.html
-.. _Comment utilisez Django avec FastCGI, SCGI ou AJP: ../fastcgi/
-
-Configuration basique
-=====================
-
-Pour configurer Django avec mod_python, assurez vous qu'Apache est installé, 
-et que mod_python est activé.
-
-Ensuite éditez votre fichier ``httpd.conf`` et ajoutez-y ce qui suit::
-
-    <Location "/mysite/">
-        SetHandler python-program
-        PythonHandler django.core.handlers.modpython
-        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
-        PythonOption django.root /mysite
-        PythonDebug On
-    </Location>
-
-...et remplacez ``mysite.settings`` par le nom du répertoire de votre projet Django
-où se trouve votre fichier settings.py.
-
-Cela indique à Apache : "Utilise mod_python pour toutes les URL sous le chemin 
-'/mysite/', en utilisant l'handler Django de mod_python." Cela lui fournit la 
-valeur définie pour ``DJANGO_SETTINGS_MODULE`` et ainsi, mod_python sait quels 
-paramètres utiliser.
-
-**Nouveau dans la version de développement de Django :** Du fait que
-mod_python ne sait pas que le site est affiché sous le chemin ``/mysite/``,
-cette valeur doit être fournie au handler de mod_python via la ligne
-``PythonOption django.root ...``. La valeur donnée à cette ligne (le dernier
-élément) doit correspondre à ce qui est indiqué dans la directive ``<Location
-...>```. Par conséquent, Django va automatiquement supprimer la chaine
-``/mysite`` du début de chaque url avant de les faire correspondre à vos
-règles de configuration d'url définies dans ``URLConf``. Si vous déplacez votre
-site sous le chemin ``/mysite2``, vous n'aurez rien à faire excepté modifier
-l'option ``django.root`` dans le fichier de configuration apache de votre site.
-
-Lorsque vous utilisez l'option ``django.root``, assurez-vous que ce qui reste
-après le préfix (ie /mysite) commence bien par un slash (/). Vos règles de
-configuration d'URL (URLConf) qui commencent par un slash fonctionneront
-correctement. Dans l'exemple ci-dessus, puisque ``/mysite/admin/`` doit
-renvoyer vers ``/admin/``, il nous suffit de supprimer la chaine ``/mysite``
-de cette occurence puisqu'il s'agit de la valeur définie pour ``django.root``.
-Utiliser ``/mysite/`` (avec un slash final), serait une erreur dans le cas
-présent.
-
-Notez que nous utilisons la directive ``<Location>`` et non ``<Directory>``. 
-Cette dernière est utilisée pour pointer sur des emplacements dans votre 
-système de fichiers, alors que ``<Location>`` porte sur le motif de l'url de 
-votre site web. ``<Directory>`` n'a aucun sens ici.
-
-En outre, si votre projet Django n'est pas dans le ``PYTHONPATH`` par défaut 
-de votre ordinateur, vous devez indiquer à mod_python où se situe le projet :
-
-.. parsed-literal::
-
-    <Location "/mysite/">
-        SetHandler python-program
-        PythonHandler django.core.handlers.modpython
-        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
-        PythonOption django.root /mysite
-        PythonDebug On
-        **PythonPath "['/path/to/project'] + sys.path"**
-    </Location>
-
-La valeur que vous utilisez pour le ``PythonPath`` doit contenir tous les 
-répertoires parents des modules que vous importez dans votre application. 
-Elle doit aussi contenir le dossier parent de votre fichier 
-``DJANGO_SETTINGS_MODULE``. Cela est en tout point similaire à la définition 
-du Python Path pour un usage interactif. A chaque fois que vous tentez 
-d'importer quelque chose, Python va regarder dans les répertoires de votre 
-``sys.path``, du premier au dernier, puis va tenter d'importer le(s) module(s) 
-depuis chaque répertoire jusqu'au chargement effectif du module. 
-
-Un exemple pour éclaircir ces propos : Supposez que vous avez une application 
-située dans ``/usr/local/django-apps/`` (par exemple : 
-``/usr/local/django-apps/weblog/``), que votre fichier de paramètres est 
-``/var/www/mysite/settings.py`` et que vous avez défini 
-``DJANGO_SETTINGS_MODULE`` comme dans l'exemple précédent. 
-Dans ce cas, vous allez définir votre directive ``PythonPath`` directive de la 
-façon suivante::
-
-    PythonPath "['/usr/local/django-apps/', '/var/www'] + sys.path"
-
-Avec ce chemin, ``import weblog`` and ``import mysite.settings`` vont 
-fonctionner. Si vous avez ``import blogroll`` dans votre code et si 
-``blogroll`` est située dans le répertoire ``weblog/``, alors vous devez 
-*également* ajouter ``/usr/local/django-apps/weblog/`` à votre directive 
-``PythonPath``. Rappel: Le **répertoire parent** de tout ce que vous importez 
-doit être défini dans votre Python path.
-
-.. note::
-
-    Si vous utilisez Windows, il est recommandé d'utiliser les "slashs"
-    dans la désignation du chemin, même si les "anti-slashs" sont utilisés 
-    nativement. Apache sait comment convertir les slashs en anti-slashs.
-    En procédant ainsi, votre configuration est portable sur un autre 
-    environnement et gagne en lisibilité (cela évite surtout d'échapper vos 
-    anti-slashs).   
-
-    Ceci est valide même sous un système Windows::
-
-        PythonPath "['c:/path/to/project'] + sys.path"
-        
-Vous pouvez aussi ajouter des directives telles que ``PythonAutoReload Off`` 
-pour améliorer les performances. Référez vous à la 
-`documentation de mod_python`_ pour la liste complète des options.
-
-Notez que vous devez utiliser ``PythonDebug Off`` sur un serveur de 
-production. Si vous avez ``PythonDebug On``, vos utilisateurs vont voir les 
-tracebacks Python hideux et révélateur en cas d'erreurs avec mod_python.
-
-Redémarrez Apache, et toutes les requêtes vers /mysite/ seront servies par 
-Django. Note que la configuration des urls de Django n'analyse pas "/mysite/" 
--- c'est bien toute l'url qui lui est passé.
-
-Quand vous déployez des sites réalisés avec Django avec mod_python, vous 
-devrez redémarrez Apache à chaque fois que vous modifiez votre code Python.
-
-Installations multiples de Django au sein d'une seule instance Apache
-=====================================================================
-
-Il est tout à fait possible d'exécuter plusieurs instances de Django sur la 
-même instance Apache. Il faut juste utiliser les `VirtualHost`` comme indiqué 
-ci-dessous ::
-
-    NameVirtualHost *
-
-    <VirtualHost *>
-        ServerName www.example.com
-        # ...
-        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
-    </VirtualHost>
-
-    <VirtualHost *>
-        ServerName www2.example.com
-        # ...
-        SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
-    </VirtualHost>
-
-Si vous avez besoin d'utiliser plusieurs instances au sein du même 
-``VirtualHost``, vous devez vous assurer que le cache de mod_python n'ait pas 
-d'effets de bord.  Utiliser la directive ``PythonInterpreter`` au sein de 
-chaque section ``<Location>`` pour contourner le problème::
-
-    <VirtualHost *>
-        ServerName www.example.com
-        # ...
-        <Location "/something">
-            SetEnv DJANGO_SETTINGS_MODULE mysite.settings
-            PythonInterpreter mysite
-        </Location>
-
-        <Location "/otherthing">
-            SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
-            PythonInterpreter othersite
-        </Location>
-    </VirtualHost>
-
-Les valeurs données à ``PythonInterpreter`` importent peu tant qu'elles sont 
-différentes pour chaque section ``Location``.
-
-Mettre en place un serveur de développement avec mod_python
-===========================================================
-
-Si vous utilisez mod_python en tant que serveur de développement, vous pouvez 
-éviter la contrainte de redémarrer le serveur à chaque modification de code. 
-Il vous suffit de définir ``MaxRequestsPerChild 1`` dans votre fichier 
-``httpd.conf`` pour forcer Apache à se recharger à chaque requête. Mais ne 
-faites surtout pas ça sur un serveur de production, faute de quoi nous vous 
-interdirions de jouer avec Django.
-
-Si vous êtes le genre de programmeur à débugguer en utilisant des instructions 
-``print``, notez que l'instruction ``print`` n'a aucun effet sous mod_python ; 
-Elle n'apparaît pas dans le log d'apache comme certains s'y attendent. Si vous 
-avez besoin d'afficher les informations de débuggage sous mod_python, utilisez 
-plutôt ::
-
-    assert False, the_value_i_want_to_see
-
-Ou ajoutez les informations de débuggage dans votre modèle de page.
-
-.. _documentation de mod_python: http://modpython.org/live/current/doc-html/directives.html
-
-Servir les fichiers média
-=========================
-
-Django ne sert pas de lui-même les fichiers media. Il laisse cette tâche au 
-serveur web que vous avez choisi.
-
-Nous recommandons l'utilisation d'un serveur web distinct, i.e. un qui soit 
-différent de celui sur lequel tourne Django, pour servir les fichiers media. 
-Ci-après quelques bons choix :
-
-* lighttpd_
-* TUX_
-* Une version allégée d'Apache_
-
-Si, toutefois, vous n'avez pas cette possibilité et devez servir les fichiers 
-media sur le même hôte virtuel Apache, voici comment désactivez mod_python 
-pour une partie du site ::
-
-    <Location "/media/">
-        SetHandler None
-    </Location>
-
-Adaptez ``Location`` en fonction de l'url racine de vos fichiers media. Vous 
-pouvez aussi utiliser la directive ``<LocationMatch>`` pour satisfaire une 
-expression régulière.
-
-L'exemple suivant définit que Django est à la racine du site mais le désactive 
-pour le dossier ``media`` et toute url se terminant par ``.jpg``, ``.gif`` ou 
-``.png``::
-
-    <Location "/">
-        SetHandler python-program
-        PythonHandler django.core.handlers.modpython
-        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
-    </Location>
-
-    <Location "media">
-        SetHandler None
-    </Location>
-
-    <LocationMatch "\.(jpg|gif|png)$">
-        SetHandler None
-    </LocationMatch>
-
-
-.. _lighttpd: http://www.lighttpd.net/
-.. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
-.. _Apache: http://httpd.apache.org/
-
-Servir les fichiers media d'admin
-=================================
-
-Notez que le serveur de développement de Django sert automatiquement les 
-fichiers media d'admin mais ce n'est plus le cas si vous utilisez une autre 
-configuration. Vous devez configurer Apache, ou tout autre serveur web 
-utilisé, pour servir les fichiers d'admin.
-
-Les fichiers d'admin sont situés dans (``django/contrib/admin/media``) dans la 
-distribution de Django.
-
-Ci-après les deux approches recommandées :
-
-    1. Créer un lien symbolique vers les fichiers media d'admin depuis la 
-       racine de votre site. Ainsi, tous les fichiers dépendants de Django 
-       (code **et** modèles) demeurent à un seul endroit,   et vous serez 
-       toujours en mesure de mettre à jour votre code vers les derniers 
-       gabarits d'admin via ``svn update``, si ces gabarits changent.
-    2. Ou copiez les fichiers media d'admin de telle sorte qu'ils soient 
-       présents à la racine de votre site.
-
-Utiliser des eggs avec mod_python
-=================================
-
-Si vous avez installé Django à partir d'un egg_ ou si vous utilisez des eggs
-dans votre projet Django, une opération supplémentaire est requise. Créez un
-fichier dans votre projet (ou ailleurs) contenant les éléments suivants::
-
-    import os
-    os.environ['PYTHON_EGG_CACHE'] = '/some/directory'
-
-Ici, ``/some/directory`` est un répertoire dans lequel Apache doit pouvoir 
-écrire. Les eggs vont utiliser ce répertoire pour y placer tout le code 
-nécessaire à leur fonctionnement
-
-Ensuite, vous devez indiquer à mod_python qu'il lui faut importer ce fichier 
-avant de faire quoi que ce soit. Cela se fait en utilisant la directive 
-PythonImport_ de mod_python. Vous devez vous assurer que vous avez bien défini 
-la directive ``PythonInterpreter`` pour mod_python comme décrit précédemment__  
-(vous devez faire cela même si vous n'utilisez pas les installations multiples).
-
-Ensuite, ajoutez la ligne ``PythonImport`` dans le fichier de configuration 
-principal de votre serveur (c'est à dire en dehors des sections ``Location`` 
-ou ``VirtualHost``). Par exemple::
-
-    PythonInterpreter my_django
-    PythonImport /path/to/my/project/file.py my_django
-
-Note : vous pouvez utiliser un chemin absolu (ou un chemin d'import normal, 
-marqué par des points), comme décrit dans le `manuel de mod_python`_. Nous 
-utilisons un chemin absolu dans l'exemple ci-dessus, car, si n'importe quelle 
-modification du path python est requise pour accéder à votre projet, elle ne 
-sera pas effectuée lorsque la ligne ``PythonImport`` est interprétée.
-
-.. _egg: http://peak.telecommunity.com/DevCenter/PythonEggs
-.. _PythonImport: http://www.modpython.org/live/current/doc-html/dir-other-pimp.html
-.. _manuel de mod_python: PythonImport_
-__ `Installations multiples de Django au sein d'une seule instance Apache`_
-
-Gestion des erreurs
-===================
-
-Quand vous utilisez Apache/mod_python, les erreurs seront attrapées par Django
- -- en d'autres mots elles ne seront pas remontées à Apache et n'apparaîtront 
- pas dans le fichier ``error_log`` de ce dernier.
-
-La seule exception est que si quelque chose de vraiment étrange est présent 
-dans la configuration de votre instance Django. Dans ce cas, vous verrez une 
-page "Internal Server Error" dans votre navigateur et le traceback python 
-complet dans le fichier ``error_log`` d'Apache. Le "traceback" dans le 
-``error_log`` est réparti sur plusieurs linges. (Oui, c'est moche et plus 
-complexe à lire mais c'est la façon dont mod_python 
-gère les choses.)
-
-Si vous obtenez une erreur de segmentation (segmentation fault)
-===============================================================
-
-Si Apache provoque une erreur de segmentation, il y a deux causes probables 
-qui ne sont pas imputables à Django.
-
-    1. Cela est peut être dû à votre code python qui importe le module 
-       "pyexpat", qui peut rentrer en conflit avec la version embarquée dans 
-       Apache. Pour plus d'information, consultez `Expat Causing Apache Crash`_.
-    2. Cela peut être du au fait que vous faites tourner mod_python et mod_php 
-       dans la même instance d'apache avec MySQL comme base de données. Dans 
-       certains cas, cela cause une erreur connue de mod_python due à un 
-       conflit de version entre le backend Python et PHP de MySQL. Plus 
-       d'information dans l'`entrée de la FAQ de mod_python`_.  
-       
-Si les problèmes persistent dans votre mise en place de mod_python, une bonne 
-chose à faire est de tester un site sous mod_python et qui n'a pas été réalisé
-avec le framework Django. Il s'agit d'un moyen simple pour isoler les 
-problèmes spécifiques à mod_python. La page `Getting mod_python Working`_ 
-détaille cette procédure.
-
-L'étape suivante serait d'éditer votre code de test et d'importer ajouter 
-n'importe quel bout de code spécifique Django que vous utiliser -- vos vues, 
-modèles, configuration d'url, configuration RSS, etc. Mettez ces bouts de code 
-importer dans votre function de test au sein de votre handler et accédez-y 
-avec votre navigateur. Si cela conduit à un crash, vous venez de confirmer que 
-c'est le code Django importé qui pose problème. Réduisez progressivement la 
-taille du code importé jusqu'à ce que le crash n'ait plus lieu afin de trouver 
-le module qui pose problème. Plonger dans les modules et les modules importés 
-xsdepuis ces premiers modules si nécessaire. 
-
-.. _Expat Causing Apache Crash: http://www.dscpl.com.au/articles/modpython-006.html
-.. _entrée de la FAQ de mod_python: http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp
-.. _Getting mod_python Working: http://www.dscpl.com.au/articles/modpython-001.html
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.