Aujourd’hui, j’ai l’impression de me retrouver au début de l’ADSL avec les framework Web de tout langage, et voire même entre différents framework d’un même langage. Le mien est mieux que le tiens parce que blablabla

Exemple :

• Python/Ruby contre PHP
• Django (un framework web en python) versus Ruby On Rails (un framework web en Ruby évidement:) .
• Symfony (un framework PHP) versus tous les autres (ZendFramework, Jelix, CakePHP etc…)

Coté Python/Ruby, si on parle de noob (débutant) de développeur web, c’est pour déblatérer sur PHP. C’est sûr que, vu de l’extérieur, de tels propos donne envi d’entrer dans une sphère côtoyée par des développeurs puérils et/ou manquant cruellement d’humilité.

Au sein de la communauté PHP, on ne jure(rait) (en France) que par Symfony car c’est le framework qui a le vent en poupe et a(urait) permis à PHP de faire son entrée dans le monde professionnel.
A tel point qu’on en arrive à « s’exposer », telle une affiche « Reward Dead or Live $10000″ (à la Au nom de la loi) qui fait tout autant peur qu’une vraie.

Fort heureusement ce n’est pas le seul sur la toile et selon les continents, il n’existe même pas : ZendFramework serait plus répandu aux Etats-Unis, CakePHP en Asie.
On peut se dire que les échanges entre les auteurs de framework, la communauté, et PHP auront bien contribué à sa professionnalisation, et c’est tant mieux !

Pour autant nombreux sont ceux qui se sont posés la question de lâcher PHP pour une autre « vie » sous d’autres cieux (Django / RoR, autres).

Mais alors pour en revenir à mon introduction sur un « fournisseur ADSL qui marche où je suis », ne serait-il pas plus judicieux de choisir, un framework Web selon ses besoins du moment, et cesser de dénigrer celui d’en face ?

Donc je me suis farci le site http://www.djangoproject.com/ en long en large et en travers à la recherche d’un PDF, mais en vain.

En faisant une petite recherche sur google, je me jette sur un vieux billet de 2008, qui indique la marche à suivre pour … se générer la documentation soi-même.

Ok, je vais pas m’arrêter là, suis motivé :-)

hop installation des outils easy_install et du support latex

apt-get install python-setuptools
apt-get install python-plastex
apt-get install python-sphinx
apt-get install texlive-full (necessaire sinon erreur à la compilation latex=>pdf)


Mais au moment de la compilation sur ma debian (5.0) via :

sphinx-build -b latex . build_latex

l’avion crash en plein vol …

The process fails when it tries to do an import:
from sphinx.directives.desc import option_desc_re

Bon, pour ne pas passer pour un enquiquineur de première sur la ML django-fr, je m’en retourne voir google, et nouvelle trouvaille

J’apprends là bas qu’il faut une mise à jour issue tout droit du trunk django, et qui consiste donc à copier le fichier djangodocs.py en lieu et place de celle de la 1.2.1…. et rebuilder

Reste donc enfin à produire le pdf :)
latex build_latex/django.tex django.pdf

Et là miracle, ca repète :)
tex capacity exceeded, sorry [save=5000]

rebelote google tout çaaaaaaaaaaaa
on doit donc éditer
/usr/share/texmf/web2c/texmf.cnf
et changer la valeur de save_size

retestage :
latex build_latex/django.tex django.pdf
Output written on django.pdf (1032 pages, 5261614 bytes)

Aaaaaaaaaaaaah enfin je peux le transférer dans iBooks sur l’iPodTouch

Quel périple juste pour un PDF, gageons que la suite sera moins « rigolote » .

Ben en fait c’est pas génial :/ dans le PDF, le code écrit en noir sur fond noir ça le fait pas du tout.

EDIT : après un retour à la doc du projet lui même j’ai fini par faire plus simple et ça marche :

Donc on se rend dans le dossier « doc » et on tape juste :
make latex
puis
cd _build/latex
make all-pdf
pour obtenir
Output written on django.pdf (1057 pages ...)
et cette fois ci on a le code illustrant la doc tout à fait lisible :)

La Doc Django 1.2.1 en PDF est doc là :)

EDIT2 : c’est bien lisible dans iBooks :D à moi le mille feuilles dans le RER :-)

Mais depuis hier la décision de migrer à Django est tombée.

En tant qu’utilisateur de PHP je ne me rejouis pas de la façon dont les choses sont présentées.
On verra comment ils s’y prennent mais déjà ils commencent en se distinguant sur le SCM choisi : Git alors que les autres projets Mozilla utilisent Mercurial

Source AMO