Un Electron Libre...

Archlinux disposant d'une fort vieille version de SPE, je me suis décidé à mettre à jour le fichier PKGBUILD existant en partant de ce qui existait originellement et aussi du paquet spe-svn (paquet orphelin, tout comme spe jusqu'à ce soir).

Cela donne donc SPE 0.8.4.c pour Archlinux.

Pour l'installer :

yaourt -S spe

Par contre, sous Debian Testing, spe ne fonctionne pas suite à un problème de dépendances sur wxpython

Dans le monde python, il y a :

• Une syntaxe de documentation puissante mais pas aisée à prendre en main : ReST, pour ReStructured Text, fourni via docutils. Voir la QuickRef de ReST.
• Pygments, un système de coloration syntaxique, un peu comme GeSHi en PHP.

Dans vos documents rédigés en ReST, il est possible d'inclure Pygments pour enrichir le rendu de vos documents.

Il vous faut pour cela :

• docutils installé sur votre ordinateur,
• pygments aussi
• récupéré le fichier external/rst-directive.py présent dans le fichier source de pygments 0.9 et le copier dans /usr/lib/python2.5/site-packages/docutils/parsers/rst/directives/

Ensuite, et c'est là où le système manque un peu de flexibilité, il faut déclarer cette directive :

• Editer /usr/lib/python2.5/site-packages/docutils/parsers/rst/directives/init.py (il y a deux "_" de chaque coté du init - bug de DC2 apparemment) pour ajouter une ligne :

_directive_registry = {
      'sourcecode': ('rst-directive', 'pygments_directive'),
      'attention': ('admonitions', 'Attention'),
      ...
      }

Cette déclaration dit que quand j'utiliserais la directive sourcecode dans mon document ReST, alors il doit aller utiliser la classe pygments_directive présente dans le fichier rst-directive.py.

• Editer le fichier /usr/lib/python2.5/site-packages/docutils/parsers/rst/languages/en.py (et les éventuelles traductions) :

directives = {
      # language-dependent: fixed
      'sourcecode': 'sourcecode',
      'attention': 'attention',
      ...
      }

Voilà pour l'installation de pygments et docutils.

Dans votre texte au format ReST, il vous suffit d'utiliser la directive sourcecode comme dans l'exemple suivant :

Tutoriel : partie 1
===================

settings.py
-----------

.. sourcecode:: python

    # Django settings for tutoriel project.

    DEBUG = True
    TEMPLATE_DEBUG = DEBUG

    ADMINS = (
        # ('Your Name', 'your_email@domain.com'),
    )

Si vous voulez que les numéros de lignes soient également mentionnés, il vous faut décommenter la ligne suivante (dans rst-directives.py) :

et modifier votre fichier de la façon suivante (ajout de la directive :linenos: :

Tutoriel : partie 1
===================

settings.py
-----------

.. sourcecode:: python
    :linenos:

    # Django settings for tutoriel project.

    DEBUG = True
    TEMPLATE_DEBUG = DEBUG

    ADMINS = (
        # ('Your Name', 'your_email@domain.com'),
    )

Je vous fais grâce du code html de rendu, surtout que pour le moment, je n'ai pas de coloration syntaxique (cf Pygments et ReST Partie 2)

Je viens juste de soumette mon troisième paquet pour ArchLinux, à savoir mod_wsgi.

mod_wsgi est un module pour le serveur web Apache et se veut une alternative à mod_python ou mod_fastcgi/mod_cgi pour les applications python. Il a pour objectif de supporter toute application compatible WSGI (Trac, Django, etc).

Il se veut plus performant que mod_python et fonctionne sous deux modes :

• Un mode "embarqué", de façon similaire à mod_python, mod_php, etc : les applications wsgi partagent les mêmes process Apache que les applications utlisant les modules php, perl, etc.
• Un mode "service", de façon similaire à mod_fastcgi : ce mode permet d'isoler les applications wsgi des autres applications hébergées. Ainsi les process Apache ne sont pas surchargées par le modules pour rien. Dans ce mode, mod_wsgi pourrait donc être utilisé dans le cadre d'un hébergement mutualisé par ex.

Voilà pour une présentation rapide du mod_wsgi. Pour le reste, je vous invite à consulter la documentation en ligne.

C'est encore la faute à Niko qui me demandait pourquoi je n'étais pas parti sur un framework PHP ou sur (Ruby on) Rails pour le projet Atome.

Mes raisons sont assez simples :

• C'est en lisant "Apprendre à programmer en python" que j'ai découvert python et compris le fonctionnement de la programmation orienté objet et les notions de classes, méthodes, etc.
• Python est un langage universel dans le sens où on peut aussi bien faire des scripts batch, que des applications graphiques ou du développement web (contrairement à PHP, même s'il y a un php-cli et php-gtk)
• David m'avait bien vendu python lors d'échanges par mail,
• le modèle objet de PHP reste obscure pour moi avec ces -> et ces $this

Maintenant que j'ai un début de blog qui tourne sous django (comprendre je peux créer/modifier/supprimer des billets, les assigner à des catégories et/ou tags, lister les catégories/tags et lister les billets d'une catégorie ou d'un tag), je me demande si je ne vais pas m'occtroyer une petite pause dans mon développement (pourtant, ce matin dans le train, je me suis noté 25 tâches à faire pour terminer ce projet ).

Cette pause consisterait à recréer ce que j'ai fait pour le moment sous Django sous d'autres frameworks pour voir ce que j'en pense en vrai

La liste des prétendants pourrait être la suivante :

• Framework PHP : Symfony, mais c'est peut être sortir un tank pour pas grand chose...
• Framework Ruby : Rails

Brièvement, le projet Atome a pour objectif de permettre d'avoir en un seul et unique endroit, un espace "blog" et un espace "tutoriel" avec tout ce qui va bien (commentaire threadé, tags, catégories, flux rss/atom, trackbacks, pings, coloration syntaxique, éditeur riche (pas forcément wysiwyg...), urls propres, etc).

et toi cher lecteur, qu'en penses-tu de cette idée ? que ferais-tu à ma place ?

Dans Django, il est possible de définir les urls à différents endroits :

• au niveau du projet : dans monprojet/urls.py
• au niveau de chaque application : dans monprojet/monapplication/urls.py

Solution 1 : vous stockez les urls au niveau du projet :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
    (r'^admin/', include('django.contrib.admin.urls')),
    (r'^app/$', 'monprojet.monapplication.views.index'),
    (r'^app/page', 'monprojet.monapplication.views.page'),
)

Solution 2 : au niveau de chaque application :

Dans monprojet/urls.py :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
    (r'^admin/', include('django.contrib.admin.urls')),
    (r'^app/', include('monprojet.monapplication.urls')),
)

et dans monprojet/monapplication/urls.py - attention à bien définir un chemin relatif (voir plus bas pour plus d'explications) :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
    (r'^$', 'monprojet.monapplication.views.index'),
    (r'^page', 'monprojet.monapplication.views.page'),
)

Vous pouvez même simplifier ce dernier élément de la façon suivante :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('monprojet.monapplication',
    (r'^$', 'views.index'),
    (r'^page', 'views.page'),
)

Pour le contenu de monprojet/monapplication/urls.py, attention à ne pas faire apparaître une deuxième fois le chemin, comme on pourrait le croire :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
    (r'^app/$', 'monprojet.monapplication.views.index'),
    (r'^app/page', 'monprojet.monapplication.views.page'),
)

Faute de quoi, django vous renverra une erreur 404 si vous appelez http://www.domain.tld/app/ car il cherchera le motif http://www.domain.tld/app/app/. Le premier "app" est en fait déjà définit dans monprojet/urls.py et le second dans monprojet/monapplication/urls.py.

En savoir plus : http://www.djangoproject.com/documentation/url_dispatch/